Baserow is a no-code database and application builder. A self-hosted instance can hold operational tables, forms, public views, automations, and AI or integration credentials. A public Baserow page may be a deliberately shared application or an internal workspace that was exposed. The owner and data boundary decide which.

What ZoomEye returned

On 2026-11-03T04:15:52Z, a count-only query with page=1, pagesize=1, and sub_type=all returned 2,274 total matches for title="Baserow". The same run returned 0 for app="Baserow". The title result is the useful discovery signal here. It does not show that a table, form, or workspace is readable by an anonymous visitor.

Baserow's official configuration and SSO documentation describe JWT lifetimes, refresh-token rotation, SSO providers, public views, and the choice between password and identity-provider login. A deployment that uses a public application builder may be intentionally reachable. An administrative workspace should have a different network and identity policy.

Separate public views from workspace access

Start with the Baserow instance URL, owner, edition, and workspace list. Identify each public view and the table it exposes. Review the fields, filters, row restrictions, and actions available to an anonymous user. Test a view with a modified URL or query parameter to see whether it can reach another table or a larger row set.

Review workspace membership and roles. A user who can edit a table may also be able to change a form, automation, or public view. Separate data editors from application publishers where the product supports it. Keep an owner for every workspace and a process for removing a departed user.

Review SSO and password login together. Baserow documents that the first authentication method used for an account affects later provider choices. Test how an account created with email and password behaves when SSO is enabled, and decide whether multiple methods are allowed. A policy that seems safe in the admin panel can be undermined by a local fallback account.

Review tokens and integrations

Baserow can use database tokens, automation credentials, and external AI or integration services. Inventory each token's owner, scope, expiry, and last use. The official configuration documentation covers JWT signing, access and refresh lifetimes, and rotation. Use the shortest lifetime that the integration can tolerate and revoke tokens through a tested process.

If an application uses a Baserow form or public view, test the submission path separately from the data path. A form can accept untrusted input that later reaches an automation or another system. Validate size limits, required fields, and the behavior of any downstream integration.

Database and cache services should be reachable only from the application network. Keep backups and AI provider keys outside the web root and version control. Review whether an application builder can make outbound requests to a private network address; the Baserow configuration documentation describes SSRF protections for configurable data-sync and SSO URLs, but the exact default depends on the deployment and version.

Use the count responsibly

Join the title matches to organization-owned domains and certificate records. For each owned host, verify the workspace and public-view policy from an internal administrative source. For an unknown host, stop after attribution and do not enumerate tables.

Monitor new title matches and changes in public-view policy. A new match under an owned domain may be a new deployment or a proxy change. A public view can be created without changing the page title, so the external count is not enough to track exposure.

The 2,274 title matches are candidate pages, not confirmed public databases. The review should identify the owner, the authentication mode, the public views, the tokens, and the integration boundary. Baserow makes data applications easy to publish, which makes a deliberate ownership and access review more important than a raw match count.

References