Backend Security: Row-Level Security, API Keys and Environment Variables

A database behind an API still needs an access plan. For each table, decide which roles can read, create, update and delete rows, and which rows each role may touch. Then keep administrative credentials out of browsers, public repositories and logs.

Check how RLS was enabled

Table grants and Row-Level Security work together: grants determine whether a database role may attempt an operation, while RLS policies filter which rows it may access. Supabase’s table guide notes that the Dashboard Table Editor enables RLS when it creates a table. Tables created with SQL or migrations may not have RLS enabled automatically, so check each table before exposing it through the Data API. Grants are a separate check: Supabase is making explicit grants mandatory for new tables in the public schema, with the change applying to existing projects on October 30, 2026. A table needs the appropriate grant to be reachable through the Data API, then RLS policies determine which rows the role can access. See the Supabase rollout notice for the project timeline and migration guidance. Supabase’s RLS guide explains how to write and test policies for each operation and user or tenant relationship.

Use publishable keys only with data controls

Supabase’s current publishable key, usually prefixed sb_publishable_, is designed for browser and mobile clients. The older anon key remains compatible, but either key is safe to expose only when table grants are limited and RLS policies enforce the access each user should have. The secret key (sb_secret_) and legacy service_role key bypass RLS and belong only in trusted backend code. Supabase’s security guide says never to expose those privileged keys in a frontend. Its API key guide says legacy anon and service_role keys are planned for deprecation by the end of 2026; use publishable and secret keys for new projects and plan a migration for older ones.

Store secrets as deployment configuration

Load API tokens and database credentials from an environment or secret manager. Keep a sample environment file with variable names and placeholder values, not real credentials. Restrict who can read production secrets, rotate them after exposure and make sure error logging redacts authorization headers.

Review the whole path: browser, API server, database role, policy and logs. A secure key cannot compensate for an endpoint that trusts a caller-supplied user ID. Enforce identity on the server, grant only what each component needs and test both allowed and denied requests during releases.

Continue with the LeadOro AI Phone Agent Stack series for the related walkthrough.