NocoDB app matches point to API token governance

NocoDB turns databases into spreadsheet-like applications. A self-hosted deployment can contain customer records, internal inventories, workflow data, and API tokens. An exposed login or application page is a starting point for inventory, but the more important questions are which workspace it serves and which tokens can reach that workspace.

What ZoomEye returned

On 2026-11-03T04:15:50Z, a count-only query with page=1, pagesize=1, and sub_type=all returned 703 total matches for app="NocoDB". The same run returned 363 for title="NocoDB". The app query is the more specific discovery signal in this batch, while the title query provides a smaller candidate set for customized pages. Neither count establishes that a workspace or token is exposed.

NocoDB's documentation describes API tokens, SSO-enabled workspaces, token permissions, and self-hosting options. A deployment can be intended for public forms or shared databases without exposing the administrative workspace. The access model depends on the edition, configuration, and the roles assigned to the token owner.

Inventory workspaces and tokens

Start with the NocoDB instance owner, base URL, database backend, and license or edition. Identify every workspace and the users who can administer it. Record whether email and password login, Google, OIDC, SAML, or another provider is enabled. Check whether SSO enforcement hides the local login form and whether a fallback path remains.

Review API tokens separately from user sessions. A token should have the narrowest project access and permission level that the integration needs. List the token owner, creation time, expiry, last use, and purpose. Rotate or disable tokens when an integration is retired or an owner changes roles.

The documentation notes that a password change revokes API tokens and other sessions, while SSO changes can leave some tokens in a different state. Test the actual lifecycle in the deployed version. A token that survives an offboarding event is an access path that the identity-provider review may miss.

Review public applications and data exposure

NocoDB can build applications and shared views that are intended for external users. Review each published view for the fields it exposes, the rows it selects, and the actions it permits. Test whether a public view can be changed to a different table or filter by altering a URL parameter.

Review file attachments and database credentials. A public table should not expose a file path that bypasses the view's access control. The database connection account should have only the permissions the application needs. Backups should not be readable from the web tier.

Apply network restrictions to the administrative interface. Put the login and API behind TLS and a reviewed reverse proxy. Restrict database and internal service ports to the application network. Review rate limits and audit logs for authentication and data changes.

Use both queries for discovery

Join the app and title matches to organization-owned domains and certificate records. For each owned host, verify the version and workspace configuration from an internal control plane. For an unknown host, attribute the domain before testing. Do not try to enumerate tokens or query records.

Track new app matches under owned domains. A new match can indicate a new deployment, a branding change, or a reverse-proxy path. A global count is less useful than a change in the organization's owned inventory. Keep the exact query and observation time with each asset record.

The NocoDB result is a reminder that low-code tools concentrate both data and credentials. A public page can be a legitimate business application. The review should identify the data owner, the token permissions, the public views, and the administrative boundary. ZoomEye gives the candidate list; token governance decides whether the list represents acceptable exposure.

References

• NocoDB, API authentication
• NocoDB, API tokens
• NocoDB, Self-hosting