PocketBase, Supabase Studio, Appwrite: your database admin is one login from the whole dataset

The fast way to build an app in 2026 is to grab a backend-as-a-service: PocketBase, Supabase, Appwrite, NocoDB, Baserow. You get a database, auth, file storage, and an API, all wired up, all running from one self-hosted container. And all of them ship with a web admin console, a browser UI that reads and writes every row, manages every user, and configures the whole backend. That console is the most powerful surface your app has, and when you self-host, it's running on a port and a path that an attacker can find.

The exposure is sharper than a CMS admin, because there's no "public content" layer softening it. This console is the database. One login stands between a stranger and every record you've ever stored. PocketBase's is rated critical for exactly that reason: the /_/ admin is full database control behind a single password.

Five backends, one shape: the database console on the open internet

These are different products with different default paths, but the finding is identical, an admin that controls the data layer, reachable without auth.

• PocketBase (/_/) - the single-binary Go backend. The admin is full database administration: every collection, every record, every user, plus schema and rules. Critical.
• Supabase Studio (self-hosted) - the Postgres-backed BaaS dashboard. The table editor, SQL editor, auth users, and storage, the whole project, manageable from the browser.
• Appwrite console (/console) - the open-source BaaS admin. Databases, users, functions, and storage buckets.
• NocoDB (/dashboard/) - turns a database into a smart spreadsheet. The dashboard is direct access to the underlying tables.
• Baserow (/login) - the open-source Airtable alternative. Databases and rows behind its login.

Each is gated on the product's own markers, the PocketBase title and bundle markers, the Supabase Studio markers, Appwrite's console meta, so a hit means that specific console is genuinely served, not that a generic path returned a page.

Why "behind a login" isn't the comfort it sounds like

A login feels like a wall, but a reachable admin login is a wall you've invited the world to push on. The same three pressures apply as any panel, credential-stuffing with passwords from other breaches, unlimited brute-forcing where there's no rate limit, and product-specific CVEs that only matter once the console is reachable, and here the prize behind the wall is the entire dataset, not just content. Worse, self-hosted backends are often stood up quickly with a default or weak admin password "to get going," and that admin is frequently the first account created, the one an attacker most expects to find. The gap between "deployed for testing" and "indexed by a scanner" is hours.

Take the console off the public internet

These consoles are operator tools. They should be reachable by you, not by the internet. The fix is network-level, plus the obvious login hygiene.

# the whole container, admin console included, on 443
# anyone hitting db.yoursite.com/_/ gets the login

Bind the admin console to localhost or an internal network and reach it through an SSH tunnel or VPN; expose only the app-facing data API to the public, with its own row-level rules doing the access control. If the console genuinely must be remote, gate it behind an IP allowlist at your reverse proxy. And give the admin account a strong, unique password with two-factor where the product supports it, never the default it shipped with.

Reading it from outside

Whether your backend's admin console answers the public internet is something a stranger settles by visiting its default path, which is the check SurfaceCheckr runs from outside with no credentials. Each probe requires the product's own content signatures, so it confirms the actual console rather than firing on any login page, and it loads only what the console serves anonymously, it never submits the login or touches a record. The finding is the one that matters most for an app built on a BaaS: your database's control panel is reachable from anywhere, and only a password is in the way. If yours turns out to be exposed, the related reads are the database admin panels like phpMyAdmin and, for the hosted-Supabase case, the service_role key that bypasses every rule you wrote.