Supabase Database and Storage postgresql-15

Apply these rules to hosted Supabase Database and standard object Storage on PostgreSQL 15. The PostgreSQL baseline supplies SQL, role, RLS, function, and server controls. These rules add Supabase's API identities, managed schemas, object policies, and delivery paths. Self-hosted stack administration, OrioleDB previews, and analytics/vector buckets are outside this scope.

API keys and user identity

• Put a publishable API key in public clients and keep secret keys and legacy service_role credentials on trusted servers. A secret key's browser rejection is not a substitute for protecting it.
• Send modern API keys in apikey; use a user's access-token JWT in Authorization when acting as that user. A publishable or secret key is not a user JWT.
• Separate administrative clients from clients acting for a user. An authenticated user's Authorization header can make a request follow that user's RLS even when the client was initialized with a service key.
• Authorize the end user's operation and resource before any service-credential action that bypasses RLS. Never expose a generic privileged database or Storage proxy to caller-selected operations.
• Verify user tokens through the project's trusted Auth verification path before making backend decisions. Do not authorize from JWT decoding or local getSession() claims; forwarding the raw token to Supabase for its own verification is a different operation.
• Rotate exposed keys and audit every active key type. Replacing a legacy key in application code does not disable the old anon or service_role credential.

RLS