Yes, people can see your Supabase project URL, and that is expected: the URL sits in your client code alongside the anon key, so anyone inspecting your app can read it. It is not a secret; it is just the endpoint your app talks to. The URL being visible is safe as long as Row Level Security protects your data, exactly like the public anon key. What matters more is that CORS is not a meaningful access control for Supabase, since the API is designed to be called from browsers, so you cannot rely on CORS to restrict who reaches your project. Row Level Security is the control that actually governs access.
Short answer
Your Supabase URL is public and meant to be, and it is safe as long as Row Level Security protects your data. Per Supabase's API keys documentation, the client uses the project URL and the public anon key, which grants only the anonymous or authenticated role, constrained by your RLS policies. The URL is just an endpoint and reveals nothing sensitive on its own. Do not rely on CORS to restrict access, since the REST API is built to be called from browsers; RLS, per Supabase's Row Level Security guidance, is the real boundary. Keep the service_role secret key server-side, and confirm RLS is enabled and tested.
Can people see your Supabase URL?
Yes. Your Supabase project URL is embedded in your client application, because the app needs it to know which endpoint to call, so anyone who inspects your app's code or network requests can read it. This is normal and unavoidable for a client that talks to Supabase directly, and it is the same for the public anon key that accompanies the URL.
Seeing the URL, though, does not hand anyone anything sensitive. It is an address, like a public API endpoint, not a credential or a key to your data. Knowing where your project lives does not grant access to what is inside it, because access is decided by the key used and the policies behind it, not by knowledge of the URL. So the visibility of the URL is expected and, on its own, harmless.
Is that safe?
It is safe as long as Row Level Security is protecting your data. The URL, combined with the public anon key, lets a client make requests as the anonymous or authenticated role, and RLS constrains those roles to exactly what your policies allow. So with RLS enabled and correct, a visible URL and public key do not expose anything you have not permitted. This is Supabase's intended design.
The safety is entirely conditional on RLS, so the real question is never whether your URL is visible but whether your policies are correct. If RLS is disabled, the public URL and key together reach whatever the anonymous role can, which is everything, so an exposed URL on a project without RLS is part of a genuine exposure. The URL itself is not the risk; missing RLS is.
Is the anon key safe alongside it?
Yes, with RLS, for the same reason the URL is. The anon key is a public client key that grants only the anonymous or authenticated role, and RLS decides what that role can read or write. Together, the URL and anon key are what your client uses to talk to Supabase, and both are meant to be present in client code. An exposed anon key on a properly secured project is a non-issue.
What is not safe to expose is the service_role or sb_secret key, which bypasses RLS entirely and has full access to your data. That key must live only on your server and never appear in client code, a repository, or an app bundle. So the rule is that the URL and the anon key can be public, while the secret key never can, and confusing the two is the dangerous mistake, not the visibility of the URL.
CORS is not your security boundary
A common misconception is that CORS restricts who can call your Supabase project, but it does not serve as a security boundary here. Supabase's auto-generated REST and auth APIs are designed to be called from browsers across origins, so the API is broadly reachable, and you cannot lock down access to your data by configuring CORS. Anyone can send a request to your public URL with your public key from any origin.
This is why relying on CORS to protect your data is a mistake. CORS is a browser mechanism about which web pages may read a cross-origin response, not a server-side access control for your database. The control that actually governs what a request can do is Row Level Security, which applies regardless of the origin. So do not treat CORS as a gate; treat RLS as the gate, and let CORS be what it is, a browser policy rather than your data protection.
What actually protects your data
Row Level Security is what actually protects your data, and it is where your effort belongs. RLS lets you write policies at the row level that decide what each role can select, insert, update, or delete, so the anonymous and authenticated roles reach only what you intend. Enable RLS on every table the client can reach, and write least-privilege policies, for example letting users access only their own rows.
Then verify the policies rather than assume them. Query your tables as the anonymous role using the public key and the visible URL, and confirm you cannot read or modify data you should not, since a policy that is too permissive is nearly as bad as none. This verification is what turns a claim that your data is protected into a fact you have checked, and it is the step that makes a public URL and key genuinely safe.
What is public versus private
Being clear about what is public and what protects data resolves most of the confusion. The table below sorts the pieces.
| Item | Is it public? | Does it protect your data? |
|---|---|---|
| Project URL | Yes, it is an endpoint | No, it is just an address |
| Anon or publishable key | Yes, meant for the client | No, RLS does |
| Service_role or secret key | Never, server-only | It bypasses RLS entirely |
| Row Level Security policies | Enforced on the server | Yes, the real control |
| CORS configuration | Permissive on the REST API | No, not an access boundary |
Read the table to place each piece. The URL and anon key are public by design, the secret key must never be, RLS is the actual protection, and CORS is not a security control for your data.
Checklist
A short check confirms your project is safe despite a visible URL. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Accept the URL is public | Do not try to hide the project URL | [ ] |
| Enable RLS | Turn on Row Level Security for every client table | [ ] |
| Test as anonymous | Confirm the anon role cannot reach protected data | [ ] |
| Keep the secret key out | Ensure the service_role key stays server-side | [ ] |
| Do not rely on CORS | Treat RLS, not CORS, as the access boundary | [ ] |
The two that matter most are enabling and testing RLS and keeping the secret key server-side, because those decide whether your public URL and key are safe. Trying to hide the URL or lock it down with CORS is effort spent on the wrong control.
Verify with a scan
The URL being public is fine, but it is worth verifying that no actual secret shipped in what you distribute, since the dangerous case is a service_role key that leaked into the client or the app build, not the visible URL. That key bypasses RLS, so its exposure is the real problem.
A scanner like PTKD.com analyzes your app build and reports findings ordered by severity and mapped to OWASP MASVS, including secrets embedded in the app, so you can confirm no secret key shipped alongside the public URL and key. To be clear about the boundary: PTKD does not configure your RLS or your CORS. It checks the build for exposed secrets, which complements the RLS work that keeps your public URL and key safe.
What to take away
- Yes, people can see your Supabase URL; it is embedded in your client and is just a public endpoint, not a secret.
- A visible URL and anon key are safe as long as Row Level Security protects your data, which is Supabase's intended design.
- CORS is not an access control for your Supabase project, since the API is built to be called from browsers, so do not rely on it.
- Row Level Security is the real boundary; enable it on every table and test as the anonymous role to confirm it holds.
- Keep the service_role secret key server-side, and verify with PTKD.com that no secret shipped alongside the public URL.
