Small self-hosted populations are easy to overlook during exposure reviews. The value of an inventory is not limited to large counts. A single invoicing instance can expose client records, invoices, payment status, and API access that reaches the same data.
What ZoomEye returned
On 2026-11-06 08:46:35 +08:00, count-only queries used sub_type=all, page 1, and pagesize 1. app="SolidInvoice" returned 0, title="SolidInvoice" returned 8, and http.body="SolidInvoice" returned 65. The title population is small in this observation, and the body query adds only a modest number of potential candidates. Neither result proves that a system is unauthenticated or that its API is exposed.
Per-user tokens and one-time display
SolidInvoice's REST API documentation says the API mirrors the web UI and authenticates with a per-user API token. Tokens are created under Settings and API Keys. The token value is displayed only once at creation. If it is lost, the documented recovery path is to revoke it and create another.
That design makes token inventory a normal administrative task. Review who has active tokens, what each integration does, when it was last used, and whether the owner still needs the account. A token generated for a temporary migration should not remain active after the migration.
Keep web and API authority aligned
Before issuing a token, define the user and role that will carry the token's authority. Confirm that the token is scoped by the same company and resource ownership checks as the web interface. The documentation advises verifying that the user owns the resource or has the correct company role and that the token was generated while that company was active.
GraphQL token management is not available through that interface. API-token listing, creation, and revocation use the REST API or the Settings page. Include this in runbooks so an operator does not assume that revoking an application integration through another interface has removed the token.
Test the lifecycle
Use a non-production account to create a token, call an authorized endpoint, attempt an unauthorized resource, and revoke the token. Confirm that the next request fails. Test the same flow after a company membership change. Record failures with request identifiers without logging the secret.
For an internet-visible instance, verify that the login, API documentation, and token-management pages require the expected authentication. Restrict administrative routes at the reverse proxy where possible, and retain access logs long enough to investigate a token that was used unexpectedly.
The external query identifies candidates. The security decision comes from the token lifecycle and the resource checks behind it.