Datasette Default Permissions Turn a Data File Into an Exposure Surface
Datasette publishes SQLite data through a web interface and API. Its default view permissions are permissive, which means the first security question is not whether the product is identifiable but whether the database was meant to be public. A bounded ZoomEye run on November 15, 2026 returned 224 matches for app="Datasette", 484 for title="Datasette" and 928 for http.body="Datasette". All queries used sub_type=all, page 1 and page size 1.
The application fingerprint is still not a deployment count. It is a field-level observation that can include documentation, demos, a hosted catalog, or a real instance. The title and body counts add different leads. For an owned domain, a successful app match is a good reason to verify the serving process and the database path, not a reason to assume data is exposed.
Datasette's authentication documentation explains that built-in view actions default to allow unless additional permission rules are configured. The --default-deny option denies anonymous and unauthenticated access, and explicit rules can grant view, query or write actions to named actors. API tokens are available through built-in and plugin mechanisms. This makes authentication and per-resource authorization two separate checks.
Review every database and table, not just the landing page. A public table can reveal row counts, columns and content even when write actions are disabled. A read-only token can still expose sensitive rows. Use a deny-by-default configuration for private data, grant only the view or query actions required by the application, and keep a separate privileged token for maintenance.
The root login URL is single-use, but it is also a powerful bootstrap credential. Treat it as an administrative secret and rotate or disable it after setup. Put the service behind a network boundary when the data is not intended for the open internet, and log token use without recording the token.
Test an anonymous instance request, an anonymous table request, a token with the wrong database, and a revoked token. The expected result is a clear 401 or 403 before SQL execution. The 224 app matches show that this fingerprint is useful. They do not replace a content owner's decision about which SQLite files belong online.
