Is my AI-built app secure? Check for exposed keys and open tables

This guide uses Supabase as the example, because many AI tools use Supabase. Other services have similar keys.

• Publishable key (the older name is anon key): This key can be in the browser. The database rules protect your data from people who have this key.
• Secret key (the older name is service_role key): This key can ignore the database rules. Keep this key on the server.

Names that start with NEXT_PUBLIC_ or VITE_ go to the browser. Do not use these names for a secret key.

1. Open the live app in your browser.
2. Press F12 to open the browser tools.
3. Click Sources.
4. Press Ctrl+Shift+F to search all files. On a Mac, press Cmd+Option+F.
5. Search for service_role, sb_secret_, sk_live_ and sk-.
6. Open your repository on GitHub and search for the same words.

1. Make a new key at the provider.
2. Put the new key in the secret settings of your host.
3. Deploy the app and test the app.
4. Remove the old key at the provider.
5. Remove the old key from your code.
6. Read the logs of the provider and find unusual use.

Row Level Security (RLS) is a set of database rules. These rules control which rows each user can read or change. If an exposed table has no RLS, a person who has the publishable key can possibly read and change the table.

1. Open your project in the Supabase Dashboard.
2. Open the Security Advisor.
3. Read each report about a table that has no RLS.
4. Enable RLS on each of these tables.
5. Write a policy for each table. A policy is one access rule.
6. Test each main task in your app.

A policy with using (true) lets all users read the data. Use this policy only for public data, such as a list of products.

This test sends a request with the publishable key only. Type this command in a terminal. Use your project address, table name and key.

curl "https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*" \
  -H "apikey: YOUR_PUBLISHABLE_KEY"

• If the result is [] or a permission error, a stranger cannot read this table.
• If the result shows rows of data, a stranger can read this table.

This test examines read access only. Also read your policies for insert, update and delete.

1. Make two test accounts, A and B.
2. Sign in as A and add a record.
3. Copy the address of the page that shows the record.
4. Open a private browser window and sign in as B.
5. Paste the address in the private window.
6. Make sure that B cannot see the record of A.

A hidden button does not protect data. The server or the database must examine each request.

• Examine your file storage. Make sure that private files are not in a public bucket.
• Find packages that have known security problems. Read how to update packages.

Stop the problem first. Then read your logs to learn what people read. Get legal advice, because laws in many countries tell you to inform your users about a data breach.