NocoDB API Tokens Make Exposure Inventory a Data-Governance Problem
NocoDB provides a spreadsheet-like interface over relational data and exposes APIs for integrations. Its documentation says every NocoDB API request needs an API token and describes token roles as an intersection with the owning user's permissions. That intersection is a useful control, but it also makes token ownership and data scope part of the external exposure problem. A reachable NocoDB instance is not necessarily a data breach. A reachable instance with an overbroad legacy token can be a much larger issue.
ZoomEye count-only queries on November 8, 2026 used sub_type=all, page 1, and page size 1. app="NocoDB" returned 702 assets. title="NocoDB" returned 367. http.body="NocoDB" returned 6,906. The application count is larger than the title count, which makes product fingerprint and title useful as independent signals. The body count is much broader and can include documentation, tutorials, and integration pages. It should not be used alone to label an instance as publicly accessible.
NocoDB's current documentation distinguishes fine-grained tokens from legacy org-wide tokens. Fine-grained tokens can be limited to projects, permission categories, and expiration on supported deployments. Legacy tokens are described as org-wide and inherit the creator's full role. On Community Edition and unlicensed self-hosted deployments, the documentation states that tokens default to all-resources access and do not expire. That makes edition and licensing a security-relevant inventory field.
A deployment review should not begin with a token value. It should begin with the token registry: token name, owning user, edition, scope model, creation date, last use, and the business integration that depends on it. Verify that each token is still needed and that the owning user's role is no longer broader than the integration. Rotate tokens after a role change, a staff departure, or an unexplained authentication event. Store tokens outside source control and do not include them in application logs.
The public surface needs its own checks. Confirm whether the instance requires authentication for the main UI and whether public shares or views are enabled. Review CORS, reverse-proxy rules, and any anonymous routes. A body match may be a marketing page for NocoDB, while a title match may be a login page. The app fingerprint is a stronger candidate for a deployed product, but the team still needs to verify ownership and the authentication boundary.
Incident response should separate exposure from authorization failure. If an internet-facing instance is found, preserve the access logs and token metadata. Determine whether any request came from an unexpected network, whether a token was used outside its expected integration, and whether the token's owner had broad project access. Do not revoke the only break-glass credential without confirming recovery access. Rotate in a controlled order and update the dependent integration.
ZoomEye adds context to the inventory by showing how different queries produce different populations. The 702 app matches and 367 title matches are candidates for ownership checks. The 6,906 body matches show why a content mention should not become a finding. The security team can sample the product candidates, compare them with the asset database, and prioritize instances where a legacy token or public share is confirmed.
NocoDB's API design makes data access convenient. The same convenience means tokens can outlive the project or role that justified them. An exposure review should therefore join the public instance inventory with the internal token inventory. The goal is not to count every page that mentions NocoDB. The goal is to find the small number of instances where a broad token and a reachable data plane create a credible path.
Query evidence
- Collection: 2026-11-08 00:44 UTC, ZoomEye SDK,
sub_type=all, page 1, page size 1. -
app="NocoDB": 702. -
title="NocoDB": 367. -
http.body="NocoDB": 6,906.
Top comments (0)