Friendica is a decentralized social server with a public profile, federation endpoints, and a node administration panel. An internet-facing instance may look like a small personal site while carrying controls that affect every account on the node. That makes owner confirmation and configuration review more useful than a broad body count.
A bounded ZoomEye SDK probe on 2026-11-12 between 00:49:05 and 00:49:08 UTC used sub_type=all, page 1, and a page size of one. The application query app="Friendica" returned 1. The title query title="Friendica" returned 300, and http.body="Friendica" returned 1,916. The one application match is a precise fingerprint but not a useful population estimate. The title and body values are candidate sets that need inspection.
Review the node administration path
Friendica's administration documentation places most server-wide settings and user management in the node's admin panel. The administrator controls federation policy, storage, addons, and configuration files. That authority is broader than a single user's social profile.
Inventory administrator accounts and their recovery paths. Confirm that the node's host-meta endpoint is reachable and serves the expected document, because federation discovery depends on it. Review the configuration files named in the documentation, including the local configuration and addon configuration. Protect those files from web access and include them in the backup and change process.
The federation document lists protocol capabilities and endpoints used to connect with other servers. Treat federation as a trust policy, not an automatic exposure decision. Determine which remote domains are allowed, how abuse reports are handled, and who can change the blocklist. A node that accepts arbitrary federation will receive content and identities from outside its administrative boundary.
Separate public and private social data
Social platforms combine public posts, followers-only content, direct messages, profile fields, and media. Review the default visibility for new posts and the controls for changing it. Check that a public profile does not expose private contact details or directory information beyond policy.
Test media access with a logged-out browser where the owner permits it. Confirm whether a file URL is protected by the same authorization model as the post that references it. Review avatar, attachment, and cache paths as separate object classes. A public image CDN can be intentional, but it should not undermine a private-post control.
Review account registration, approval, password recovery, and multi-factor options. Federated identity does not remove the need for local account security. A compromised local account can use the node's API and federation relationships even if the remote server enforces its own controls.
Build a small, owned inventory
Use the application match to identify a confirmed fingerprint and the title/body matches to find candidates that may be missing the fingerprint. Deduplicate by domain and hosting owner. Record the query, scope, count, and time for each observation. Do not convert body matches into confirmed nodes.
For each owned node, collect the version, administrator list, federation mode, domain block policy, storage configuration, registration policy, backup owner, and update path. Check the admin panel from an approved network and verify that a non-administrator account cannot reach it. Review the host-meta response and the TLS certificate as part of the public service boundary.
ZoomEye can reveal nodes that an organization did not know were public. The security decision still comes from the owner's configuration and access tests. A Federated node with one administrator and a narrow user population can still be a high-impact service if the admin credential is weak.