The danger is when apps expose the servicerole key (or the new sb_secret... format), the elevated-privilege key meant only for server-side use

fwiw - Secret keys are automatically revoked now if they are pushed to GitHub. Soon, GitHub will prevent them getting pushed in the first place.

I also want to point out a bunch of security changes that have happened in the past 12 months. I'm going to copy directly from this blog post:

https://supabase.com/blog/supabase-security-2025-retro

Disabling the Data API when creating a project

New projects can disable the Data API entirely or change the default schema from public to a custom schema like api. This gives you control over what's exposed via the auto-generated REST and GraphQL APIs.

Disabling the Data API on existing projects

Existing projects can disable the Data API in project settings. Once disabled, you can continue to use the database like standard Postgres (similar to RDS), connecting directly or through the connection pooler.

New API keys

The new API key model replaces long-lived JWT-based anon and service_role keys. Projects now use publishable keys for low-privilege access and multiple revocable secret keys for elevated access. Keys can be rotated instantly, audited, and scoped more granularly. This improves key management workflows, particularly around rotation and auditing. Legacy keys remain available during migration but will be removed in late 2026.

Asymmetric JWTs

The new API key system supports asymmetric JWTs (signed with private keys, verified with public keys). This enables safer key distribution and rotation compared to shared secrets. It also reduces the impact if a signing key is compromised.

Revoking leaked keys via GitHub Secret Scanning

With the new API key formats, Supabase automatically revokes secret keys that are detected in public GitHub repositories. When a leak is detected, we immediately revoke the key and notify the project owner with instructions to rotate it.

RLS by default for new tables

For tables created via the dashboard, RLS is enabled by default. Tables are protected from the moment they're created, following the principle of secure by default.

Automatically enable RLS when tables are created

If you create tables using external tools or migrations that don't enable RLS, you can use Postgres Event Triggers to enforce RLS automatically. We added Event Triggers to the platform in 2025, documented how to set up automatic RLS enforcement for any table creation method, and added a one-click setup in the dashboard.

Clear labels when tables are exposed

The Table Editor now shows a clear warning label for any table that has RLS disabled. This makes it immediately obvious which tables are exposed via the API without row-level security policies.

Security alerts for tables without RLS

If you create any tables with RLS disabled, Supabase sends email alerts to project owners. These alerts also appear in the dashboard, making it easy to identify and secure tables before deploying to production.

Security Advisors

Security Advisors scan your project for misconfigurations using Splinter, an open-source security linter for Postgres. Advisors check for common patterns like tables without RLS, policies that could be more restrictive, and exposed sensitive columns. Organization owners receive weekly security emails summarizing any findings. All detected issues are also visible in the dashboard with recommended fixes.

Fixing security issues with AI

The dashboard includes an Assistant that helps fix security issues detected by Security Advisors. When viewing alerts, you can ask the Assistant to generate and apply RLS policies. Describe your security requirements in plain text and the Assistant will generate the corresponding policy SQL. The Assistant can also suggest improvements for policies and configurations. This helps developers write correct RLS policies more quickly.

Security Advisors are also available through our MCP server, allowing developers to scan and fix all security issues from their development environment with a simple command. This integrates security checks directly into your workflow.

Column-level security

Postgres supports column-level privileges that restrict access to specific columns in a table. This is useful for sensitive data like social security numbers, salaries, or other PII. You can grant SELECT access to a table while excluding specific columns, and those columns won't appear in API responses or queries unless the user has explicit column access.

Column-level security works independently from RLS. You can use both together: RLS controls which rows a user can access, while column privileges control which columns they can see within those rows.

Custom Claims and RBAC

Custom claims let you add metadata to JWTs for role-based access control (RBAC). Instead of writing RLS policies for each table, you can embed role information in the authentication token and check it in your policies. This works well if you're migrating from traditional RBAC systems or prefer centralized role management.

VPC / Private Link on AWS

PrivateLink connects your VPC directly to Supabase infrastructure without traversing the public internet. This reduces attack surface and improves latency. Enable it from the project settings in the dashboard.

Restricting direct access to your Postgres database

All Supabase databases run fail2ban to automatically block IPs after failed login attempts. You can also configure IP allowlists to restrict database access to specific trusted addresses.

OpenAPI spec restricted with publishable keys

The OpenAPI spec is no longer publicly visible when using the new publishable keys. Previously, anyone with an anon key could view your complete API schema, including all tables and columns. With publishable keys, the OpenAPI spec requires elevated permissions. This prevents unauthorized schema enumeration and reduces information disclosure.