Supabase Studio discovery should stop at the management boundary
Supabase self-hosting includes a Studio dashboard for managing a project. That dashboard can be close to the database, authentication settings, storage configuration, and the credentials used by application clients. A public match for Studio therefore deserves an ownership check even when the application itself is meant to be reachable.
A count-only ZoomEye measurement on 2026-10-29 returned 368 matches for app="Supabase Studio" and 4 for title="Supabase Studio". Both used sub_type=all, page 1, and page size 1. The application fingerprint is the larger selected query. The title count shows why title-only discovery would miss most candidates in this field. Neither count proves that Studio is authenticated or vulnerable.
Keep the management plane private
Supabase self-hosting documentation says Studio is protected with HTTP basic authentication in the Docker guide. That basic check is not the same as project-level identity or network isolation. The self-hosting guide recommends keeping Studio and Postgres off the public internet and using network access controls. A strong password on a publicly reachable management console still creates a credential target and an availability dependency.
An application may expose the API, authentication service, and public storage while keeping Studio on a separate hostname. Review DNS, reverse proxy routes, security groups, and cloud firewall rules together. A hostname that should resolve only through a VPN is a policy failure if it has a public address. A 401 response at the edge is useful evidence, but it does not replace the network restriction.
For each owned deployment, identify who can reach Studio and who can administer the underlying project. Remove default credentials, disable unused sign-up pathways, and rotate administrative secrets through a documented process. Check whether Studio uses a database role with more privileges than the operator needs. Self-hosted configurations can differ from the managed platform's ownership model, so compare the deployment to the vendor's current guidance rather than assuming the defaults align.
Separate Studio from the application API
Supabase's API key documentation says each key resolves to a Postgres role and Row Level Security policies match on that role. The service-role key bypasses RLS and must remain a server-side secret. That key is materially different from an anonymous client key or a user access token. A reachable application endpoint is not automatically a compromised Studio, and a private Studio does not automatically mean RLS is correct.
Review the public API separately. Test anonymous requests, authenticated user requests, and server-side service-role use against the intended tables. Verify RLS policies with two tenants and with direct database access where possible. Ensure functions exposed through the API apply their own authorization checks and do not rely on client-supplied tenant identifiers.
Studio changes can affect the public API quickly. A policy edit, a new database function, or a storage bucket setting may expose data without changing the application's web build. Record Studio administrators and changes in an audit trail. Alert on role, policy, key, and authentication-provider changes as well as HTTP errors.
Use the query difference as a method test
The small title count is a caution against assuming that a product name in a page title is the best discovery field. For Supabase, the application fingerprint provides the stronger set. The 368 matches are still not an ownership list. Validate candidates through domains, certificates, ASNs, or an authorized scan before contacting an owner.
A practical workflow is:
- Search the organization's approved external footprint and ZoomEye evidence for Supabase candidates.
- Match each candidate to DNS, cloud inventory, and project ownership.
- Confirm that Studio is restricted to the management network.
- Review the public API and RLS independently.
- Keep the exact query, time, count, and scope with the review.
The useful outcome is a clear boundary between the public application, the public API, and the administrative Studio. ZoomEye can help find candidates at that boundary. The owner must verify the controls on each side.
Top comments (0)