The Supabase anon key and the service_role key differ in one decisive way: the anon key is public and constrained by your Row Level Security policies, so it belongs in your frontend, while the service_role key bypasses Row Level Security entirely and has full access to your data, so it must live only on a server and never in your app. The anon key going into client code is expected and safe when Row Level Security is enabled; the service_role key in client code is a full compromise. So the answer to which key goes in the frontend is the anon key, always, and the reason the service_role key cannot is precisely that it ignores the policies that make the anon key safe.
Short answer
Put the anon key in the frontend and keep the service_role key on the server. Per Supabase's API keys documentation, the anon or publishable key is designed for client use and the service_role key is a secret with high-privilege access. Per Supabase's Row Level Security docs, the anon key is constrained by policies, so it can only do what you allow, while the service_role key bypasses Row Level Security and can read, change, or delete anything. So the frontend gets the anon key, always, and the service_role key never ships in your app. If a service_role key has leaked, rotate it immediately.
Which key goes in the frontend?
The anon key goes in the frontend, and the service_role key never does. Supabase apps talk to the database directly from the client using the anon, or publishable, key, which is designed to be public and shipped in your app, so including it in your web or mobile frontend is the intended, supported setup. Because it is meant to be visible, you do not need to hide it, and hiding it would not be possible anyway since client code is inspectable.
The service_role key is the opposite: it is a secret meant only for trusted server environments, and putting it in your frontend hands anyone who inspects your app full control of your database. So the placement rule is simple and absolute. Any code that runs on the user's device or in their browser, your React, React Native, or web app, uses the anon key. Any operation that needs the service_role key runs on a server you control, whether your own backend or a Supabase Edge Function, and the key stays there. If you are unsure which key a piece of code should use, the fact that it runs on the client answers it: the anon key.
What is the anon key
The anon key is Supabase's public, client-facing key, and its safety comes entirely from Row Level Security. It carries no privileges on its own; every request made with it is subject to the Row Level Security policies on your tables, so it can only read or write the data those policies permit. That is why it is safe to embed in your app: with Row Level Security enabled and correct, the anon key is powerless beyond what you have explicitly allowed, even though anyone can see it.
The critical dependency is Row Level Security. The anon key is only as safe as your policies, so a table with Row Level Security disabled is fully open to the anon key, and a policy that grants everyone access is equally open. This is the root of most Supabase exposure incidents: not that the anon key leaked, since it is public by design, but that the database behind it had no policies constraining what that public key could reach. So treating the anon key as safe is correct only when you have paired it with Row Level Security on every table it can touch.
What is the service_role key, and the RLS bypass
The service_role key is Supabase's secret, high-privilege key, and its defining property is that it bypasses Row Level Security entirely. Where the anon key is checked against your policies on every request, the service_role key skips those checks and has full read and write access to all your data, which is by design so that trusted server code can perform administrative and privileged operations. That power is exactly why it is dangerous outside a server.
Because it ignores Row Level Security, no policy protects you if this key is exposed. An attacker with your service_role key can read every row, modify anything, and delete your data, regardless of how carefully you wrote your policies, because those policies do not apply to it. This is the single most important distinction between the two keys: your Row Level Security is the wall that contains the anon key, and the service_role key walks straight through that wall. So it must live only where you trust the environment completely, a server you control, and never in an app, a repository, or anywhere a client or a third party could obtain it.
Safe versus unsafe: the placement rule
The safe-versus-unsafe line follows directly from how the two keys relate to Row Level Security. The anon key is safe in the client because policies constrain it, so shipping it in your frontend is fine as long as Row Level Security is enabled and correct on the tables it reaches. Keeping the anon key out of your app would be pointless, since it is public by design and your protection lives in the policies, not in concealing the key.
The service_role key is unsafe anywhere a client or attacker could reach it, because nothing constrains it. It belongs exclusively on a server, and it must never appear in your app bundle, your repository, a committed configuration file, an environment variable exposed to the client, or a chat or ticket. The same applies to other true secrets like your database connection string. So the rule to remember is that the anon key ships to clients under the protection of Row Level Security, and the service_role key stays server-side because it has no such protection.
If you exposed the service_role key: rotate
If your service_role key has been exposed, in your app, your repository, or anywhere public, treat it as a full compromise and rotate it immediately, because it grants complete access that no policy limits. In your Supabase dashboard, roll the service_role key so the exposed value stops working, then update your server-side code to use the new key. Do this before anything else, since the old key remains fully dangerous for as long as it is valid.
After rotating, remove the key from wherever it leaked and move its operations to a proper server if they were not already, because reissuing the key and shipping it the same way just exposes a new secret. Review your database and logs for any signs it was used, since an exposed service_role key means an attacker could have read or altered anything. The anon key, by contrast, does not need rotating on exposure, because it is public by design and safe as long as your Row Level Security is in place; only the service_role key is an emergency.
Anon versus service_role compared
Setting the two keys side by side makes the decision obvious. The table below compares them.
| Aspect | Anon or publishable key | service_role or secret key |
|---|---|---|
| Public or secret | Public, ships in the client | Secret, server-side only |
| Row Level Security | Governed by your policies | Bypasses Row Level Security entirely |
| Access it grants | Only what policies allow | Full read and write to all data |
| Where it belongs | The frontend | A server you control |
| If it leaks | Safe when Row Level Security is on | Full compromise, rotate immediately |
Read the table by the Row Level Security row: it is the whole story, since the anon key is contained by policies and the service_role key ignores them.
Verification checklist
Working through these steps confirms your keys are placed and protected correctly. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Frontend key | Only the anon key in client code | [ ] |
| Enable Row Level Security | On every table the anon key can reach | [ ] |
| Service_role server-side | Never in the app, repository, or client config | [ ] |
| Rotate if exposed | Roll a leaked service_role key at once | [ ] |
| Verify the bundle | No service_role key in the shipped app | [ ] |
| Test the anon key | Confirm it cannot reach data it should not | [ ] |
The step that catches the worst mistake is verifying the bundle, because a service_role key in the shipped app is a full compromise that no Row Level Security policy can contain.
Scan your app for the service_role key
Because a service_role key in the client defeats every policy you set, confirming what keys actually ship is a necessary companion to writing good Row Level Security.
A scanner like PTKD.com analyzes your app build and reports issues such as leaked keys and secrets, insecure data storage, and over-broad permissions by severity, mapped to OWASP MASVS, so a service_role key that reached the client is flagged, while the anon key is expected. To be clear about the boundary: PTKD does not write your Row Level Security policies, which you manage in Supabase, and it does not enable them for you. It confirms your shipped app does not carry the secret key that would bypass the protection your policies provide.
What to take away
- The anon key is public and constrained by Row Level Security, so it belongs in the frontend; the service_role key bypasses Row Level Security and must stay on a server.
- The anon key goes in the frontend always, and the service_role key never ships in your app, because it ignores the policies that make the anon key safe.
- The anon key is safe in the client only when Row Level Security is enabled and correct on every table it reaches, since it is powerless beyond what policies allow.
- The service_role key grants full access no policy limits, so an exposed one is a full compromise and must be rotated immediately, unlike the anon key.
- Verify that only the anon key ships and Row Level Security is on, and scan your app with a tool like PTKD.com to catch a leaked service_role key.
