NocoDB makes it easy to expose a base, table or view as a shared application without giving every viewer a full account. That is often the point. It also creates a gap between "the NocoDB login is protected" and "a shared URL can read these records." Security reviews should inspect both the base permission model and the public sharing path.
NocoDB's documentation describes shared views and forms as public-access features. It also describes role-based access at workspace, base and table levels, with record-level security available in some editions. API tokens have permission scopes and expiration, and the effective permission is the intersection of the user's role and the token's permissions. Those details matter because a broad token or a view that exposes a sensitive field can bypass the comfort of an authenticated admin page.
Inventory product surfaces
On 2026-10-29 at 17:40 UTC, a ZoomEye sub_type=all query with page_size=1 returned 6801 matches for:
title="NocoDB" || http.body="NocoDB"
The query identifies pages with NocoDB product text. It does not establish that a base or view is public, and it does not measure API tokens or shared links. The result is a web-surface candidate set for owner correlation.
Map the sharing chain
For every base, record the owner, data classification, external-sharing status and the roles of its members. List the shared views and forms, including their allowed operations. Determine whether a shared view exposes fields that are restricted in the underlying table. A view can be designed to hide a column, but the review should test the actual response and not rely on the builder's preview.
Review API tokens separately. Assign the smallest base and operation scope available, set an expiry and document the consuming service. Rotate tokens after an integration change or a staff departure. If a workspace enforces SSO, verify that token access still matches the intended service account and that a disabled user's token lifecycle is understood. The effective permission is an intersection, not a sum, so a token cannot be assumed to grant more than its owner or role.
Place the NocoDB instance on a management network and use TLS. Restrict database access to the NocoDB service and require a separate database account with limited grants. A spreadsheet-like interface should not be connected to an administrative database role. Back up configuration and data, test a restore and make sure attachments or exports do not land in a world-readable object store.
Test the public path
Use a non-sensitive base in staging. Create a shared view with one visible field, open it in a private session and confirm that no other field or write action is reachable. Try a direct API request for a record outside the view's scope. Then revoke the share and verify that the old URL, a cached page and any bookmark fail in the expected way.
Test a token with a narrow permission and confirm that an operation outside that permission is rejected. Expire the token and check that the consumer fails closed. Review logs for shared-view access, token failures and permission changes. Alert on newly public bases, changes from private to public sharing and API-token creation outside the approved automation.
The operational question is not whether the NocoDB login page is protected. It is which records a person or service can retrieve through every supported path: the editor, a shared view, a form and the API. That inventory is the permission boundary users will actually experience.