Bolt Hackathon Special

You don’t need to be a security expert to build safely

But you're stepping into the world of security where you become responsible for the data you hold. I’ve put together my top tips to help you ship secure apps with Supabase

The Bare Minimum

Secrets & API Keys

• Don't put your secrets or API keys in your frontend code.

• Keep keys in .env files. Anything that reaches the browser is public.

• In Supabase there's two keys:

  • Anon Key: goes in the frontend. Read/write through RLS

  • Service Role Key: never leaves the backend/Edge Function. It bypasses RLS

Oops! You Pushed Your Secret Key to GitHub

Don't panic. It happens. You can generate new ones. The old keys are now compromised so they're useless.

You need to act ASAP:

1. Rotate Your Keys: Supabase → Settings → API → Generate new key

2. Replace Your Keys: Update .env, commit, redeploy

3. Revoke old key in other places (forks, clone repos)

4. Invalidate cached builds (Netlify: Clear cache)

Row Level Security

Supabase RLS (row level security)

Understanding RLS is a non-negotiable if you are shipping to production:

→ RLS controls which rows users can access within a table.

→ RLS operates at the individual row level.

→ It allows you to say "User A can only see their own records"

→ Or "Team members can only access data from their organization".

→ When you create tables using Supabase's Table Editor RLS is automatically enabled.

→ But there's two crucial things here:

(1) Once RLS is enabled all data becomes inaccessible via the API until you explicitly create policies.

(2) If you create a table with the SQL editor REMEMBER to enable RLS manually.

ELI5: Row Level Security

Why do you need it? If you have multiple users in your app RLS makes sure people can only access their data and not anyone else's private stuff.

How does Supabase know who's who? When a user logs into your app Supabase gives them a special ID (a JWT token). Your RLS policies use this ID to figure out who's making a request. The function is auth.uid() which tells Supabase the current user's ID.

For more detailed tutorials

Tips

4 Common RLS Mistakes to Avoid 

1. Forgetting to turn RLS on: After creating a table with the SQL editor, you need to tell Supabase to use RLS.

2. Thinking it's on by default: When you create a table with the SQL editor it's not. You have to enable it.

3. Testing with the wrong key: The Service Role Key bypasses all security (it's the admin key). When testing user access always use your Anon Key in your app.

4. Silent failures are sneaky: If your RLS policies are wrong you might not get an error just no data. Always double check your policies.

That’s it for today🤓

If you haven’t already, sign up here for the Bolt Hackathon. There’s a $1m prize pool for non-devs and vibe coders!!

I’ll be sharing more resources to help you succeed and ship a product before the hackathon deadline.

Ciara Wearen
The Prompt Driven Developer