Baserow's API is built around database and table access. The product supports personal API tokens and database tokens, and its documentation describes granular permissions down to a table. The distinction between a temporary account session and a permanent database token is the central security issue. A database token that is copied into an integration may remain valid for a long time, and its table permissions determine how much data an attacker can read or change.
Baserow documents database tokens as permanent authentication keys that do not expire. They are intended for external applications, scripts, and long-running integrations. A database token is limited to data operations such as creating, reading, updating, and deleting rows. It is not equivalent to a full account session that can change the database or table structure.
Personal API tokens and temporary JWTs have different uses. Baserow's account documentation describes personal API tokens alongside workspace permissions, while a JWT is a short-lived session credential with broader account access. Mixing these credential types in one integration without documenting the difference creates a confusing permission model.
Scope tokens to tables and operations
Create a token for a specific integration and grant only the tables it needs. Enable only the operations the workflow requires. A reporting job that reads one table should not receive create, update, and delete permissions for every table in a workspace.
Use separate tokens for development, staging, and production. A token copied into a local development environment can become a production credential if the environment variable points to the wrong instance. Name the token with its owner and purpose, but do not encode the secret in the name or commit it to a repository.
Review token permissions when the database schema or application changes. A token that was appropriate for a prototype may grant access to a newly added table in the same workspace. Check whether the workspace-level permission applies to all tables or selected tables before adding a sensitive dataset.
Make permanent credentials reviewable
A permanent token needs a lifecycle even when the platform calls it permanent. Record the owner, creation date, purpose, last rotation, and systems that store it. Set an internal expiry through rotation rather than assuming the vendor will force one.
Store the token in a secret manager or an environment variable injected at runtime. Do not put it in a URL, a spreadsheet, a support ticket, or a browser extension. A token in a client-side application can be copied by any user who can inspect the page or network traffic.
Revoke a token when the integration is retired, the owner changes teams, or the underlying database permission changes. Test revocation before relying on it during an incident. If the integration caches data, revoking the token may stop new reads without deleting previously downloaded records.
Use audit evidence and response steps
Check Baserow's audit or event records where the deployment supports them, along with the logs of the system that used the token. Identify requests to table rows, schema endpoints, and account settings. A database token should not be able to perform account-level operations, but a compromised integration may use another credential to do so.
If a token is exposed, revoke it first, then review the affected tables for unexpected writes and exports. Preserve request logs, the token identifier, and the integration configuration before cleanup. Rotate any downstream credentials that were accessible from the same environment.
If the token was used for a public or embedded view, confirm the intended exposure and the data returned. A token that only reads a public table may have a smaller impact than one with write access to an internal workflow, but the organization still needs to know what data left the system.
Measurement
ZoomEye's title="Baserow" query can find web assets whose page title matches the product label. Title matching is less precise than a confirmed application fingerprint, so the count should be treated as an inventory lead and reviewed before any ownership assumption.
On 2026-11-11, a count-only query with dork title="Baserow", sub_type=all, page 1, and page size 1 returned 2,291 matching assets. The deterministic search link is the Baserow ZoomEye query. The total is not a count of exposed tokens, confirmed vulnerabilities, or Baserow databases with sensitive data.
Compare the result with domain, certificate, and cloud inventory. A title match can include documentation sites, demos, or unrelated pages that mention the product. Validate the instance and the owner before testing authentication.
A minimum review for a Baserow deployment
List the database tokens, their workspace and table scope, the operations allowed, and the systems that hold them. Confirm that no token has broader permissions than its integration needs. Review user and workspace roles separately, because a user's role can change the permissions behind a personal token.
Test that a token denied access to a table actually receives an authorization error. Test that an expired or revoked token is rejected. Check that a temporary JWT is not being stored as if it were a permanent integration credential.
Baserow's permanent token model is convenient for automation. The convenience should be matched with a periodic access review and a tested revocation path.