Database Schema Enumeration

What Is This Vulnerability

Database Schema Enumeration is a vulnerability where an attacker can discover the structure of your database — table names, column names, data types, and relationships — through API introspection endpoints. In Supabase, the PostgREST API exposes an OpenAPI specification at the root endpoint that lists all public tables and their schemas. Firebase Realtime Database exposes its structure through the REST API with .json endpoints.

While knowing the schema does not directly expose data (if RLS or security rules are properly configured), it provides attackers with a detailed map of your data model, significantly reducing the effort needed to find and exploit other vulnerabilities.

Why It's Dangerous

Schema enumeration gives attackers a roadmap for targeted attacks:

• Table discovery — attackers learn which tables exist, including sensitive ones like payments, admin_users, or api_keys that they might not have guessed.
• Column intelligence — knowing column names like ssn, credit_card_number, or password_hash reveals what data is stored and what is worth targeting.
• Relationship mapping — foreign key relationships reveal how data is connected, helping attackers understand access patterns and identify privilege escalation paths.
• RLS bypass research — with the full schema, attackers can craft targeted queries to probe for RLS policy gaps on specific tables and columns.
• API endpoint discovery — each table corresponds to a REST endpoint, giving attackers a complete list of APIs to test.

This is rated medium because it is an information disclosure that facilitates further attacks rather than a direct data breach.

How to Detect

Test whether schema information is accessible:

# Supabase / PostgREST — fetch OpenAPI spec
curl "https://YOUR_PROJECT.supabase.co/rest/v1/" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

# Check if the response contains table definitions:
# { "paths": { "/users": {...}, "/orders": {...} }, "definitions": {...} }

# Firebase Realtime Database — probe root
curl "https://PROJECT_ID.firebaseio.com/.json?shallow=true"

# PostgreSQL information_schema via RPC (if exposed)
curl "https://YOUR_PROJECT.supabase.co/rest/v1/rpc/get_tables" \
  -H "apikey: YOUR_ANON_KEY"

AuditYour.app retrieves the API schema and analyzes it for sensitive table and column names, flagging tables that likely contain PII or financial data.

How to Fix

Limit schema exposure by controlling which tables are visible through the API:

-- Move sensitive tables to a private schema not exposed by PostgREST
CREATE SCHEMA private;

-- Move tables that should not be API-accessible
ALTER TABLE api_keys SET SCHEMA private;
ALTER TABLE admin_settings SET SCHEMA private;
ALTER TABLE audit_logs SET SCHEMA private;

-- Grant access only to the service_role, not anon or authenticated
GRANT USAGE ON SCHEMA private TO service_role;
GRANT ALL ON ALL TABLES IN SCHEMA private TO service_role;

-- Alternatively, revoke anon access to specific tables
REVOKE ALL ON public.sensitive_table FROM anon;
REVOKE ALL ON public.sensitive_table FROM authenticated;

For tables that must remain in the public schema but should not be queryable by anonymous users:

-- Enable RLS and create a deny-all policy for anon
ALTER TABLE internal_config ENABLE ROW LEVEL SECURITY;

CREATE POLICY "No anonymous access"
  ON internal_config FOR ALL
  USING (auth.role() != 'anon');

Additional mitigations:

• Use Supabase's API Settings to control which schemas are exposed via the REST API.
• Consider using database views to expose only the columns needed by the frontend.
• Disable the OpenAPI documentation endpoint in production if your frontend does not rely on it for auto-generated types.