Akkoma admin APIs make instance-wide token control the priority
Akkoma is a federated social platform, so its public timeline and federation endpoints can dominate an external view. The more important security surface is often the administrative API. An instance administrator can manage users, invitations, and configuration through endpoints that operate across the whole node.
A bounded ZoomEye SDK probe on 2026-11-12 between 00:49:00 and 00:49:04 UTC used sub_type=all, page 1, and a page size of one. The application query app="Akkoma" returned 0. The exact title query title="Akkoma" returned 740, and http.body="Akkoma" returned 1,047. The title result is the candidate set for this review. The body count may include documentation, clients, and references outside the hosted instance.
Protect the administrative identity
Akkoma's admin API documentation states that authentication is required and the user must be an administrator. That is the expected gate, but the credential behind it determines the actual exposure. The configuration documentation discourages a static, rarely changed instance-wide token because it is weaker than a real administrator login. It recommends HTTP Basic authentication or OAuth-based authentication where appropriate.
Review every credential that can call the admin API. Confirm the account, role, creation source, purpose, and rotation date. Remove static tokens that are no longer needed. If an automation must use an administrator identity, give it a dedicated account and limit what the automation can do outside the API. A token stored in a configuration file or a chat integration deserves a separate secret-management review.
Check the reverse proxy and public routing. The admin path should not be exposed more broadly than necessary. If it is reachable from the internet for administrative convenience, require strong authentication, network filtering, and logging. A login page at a public host does not prove that the admin API is safely configured.
Review federation and user management
Federation creates identities and content relationships outside the local node. The administrator still needs a policy for inbound and outbound federation, blocked domains, invitations, and account approval. Inventory the settings that alter those boundaries and record who can change them.
The Mastodon-compatible API documentation notes that user roles can be exposed in API responses when a setting enables it. Decide whether that disclosure is acceptable for the instance. Also review invite creation, password reset, email verification, and account deletion. A federated account that is removed locally may remain in remote caches. The operator should know which data is under local control and which depends on other instances.
Test a role change and a deactivation. Confirm that the user loses the intended API access and that existing sessions or tokens do not continue indefinitely. Review the frontend admin surface and the API as separate paths to the same authority.
Turn observations into an owner list
The 740 title matches should be grouped by domain, host, and owner where that information is available. Confirm whether each candidate is an active instance, a staging node, a client page, or a documentation reference. The 0 application count is a fingerprint result, not a statement that no Akkoma service exists.
For each owned instance, record the version, federation policy, administrator accounts, static tokens, invite policy, storage backend, and update process. Check the admin API from an approved test network. Preserve the query and observation time so a later comparison uses the same measure.
ZoomEye helps find candidate nodes and measure the visible population. Akkoma's security result depends on the administration and federation choices made by the node owner. Instance-wide API access should be treated as a high-value control plane, even when the public timeline looks ordinary.
Top comments (0)