The worry behind this question is reasonable, but it points at the wrong threat. App Store reviewers do not log into your Supabase project or query your tables. They test your app the way any user would. So the real question is not whether a reviewer can see your data, but what your app exposes to anyone holding the anon key, because that is the surface a reviewer, or anyone else, actually touches. Here is who can see what, and how to make sure the answer is "only what you intended."
Short answer
No, App Store reviewers do not get direct access to your Supabase database. They interact with your app as a normal client, so what they can see is whatever your app exposes through the anon key and your Row Level Security policies. That is the point that matters: the Supabase anon key is meant to be public and ships in your app, so if RLS is off or a policy is set to true, your data is readable by every client, a reviewer included, and by anyone who extracts the key from your binary. The protection is correct RLS, not hiding the key.
What you should know
- Reviewers test the app, not the database: they have no direct access to your Supabase project.
- The anon key is public: it ships in your app and is not a secret.
- RLS is the real guard: Row Level Security decides what any client can read or write.
truepolicies expose everything: a policy that allows all makes the table public.- The risk is not the reviewer: it is anyone with the anon key and weak RLS.
Do App Store reviewers access your database directly?
No. App Review evaluates your app by running it on a device against the App Review Guidelines, the same way a user would. Reviewers do not have your Supabase dashboard login, your database password, or any direct connection to your Postgres instance, so they cannot browse your tables. What they can do is use the app, and the app talks to Supabase with the anon key over its API. So anything the app can fetch and display, a reviewer can see, and anything your RLS blocks, the app cannot fetch in the first place. The reviewer is just a client, with no special access beyond what your own configuration grants every client.
What can actually be seen, and by whom?
The answer depends entirely on your Row Level Security. The table makes the access model concrete.
| Who | Direct database access? | What they can read |
|---|---|---|
| App Store reviewer | No | Only what the app exposes via the anon key and RLS |
| A normal user | No | Only what RLS allows for their role |
| Anyone with the anon key | No dashboard access | Everything if RLS is off or set to true |
| You, the developer | Yes, via the dashboard | Everything |
The pattern is clear: nobody outside your team gets dashboard access, but everybody outside your team gets exactly what RLS permits through the public anon key. A reviewer is not a privileged case; the exposure is the same for any client.
How do you make sure your data is protected?
Enable Row Level Security on every table and write policies that scope access to the right user. The default posture should be that RLS is on and a row is only readable or writable by the user who owns it, typically by matching the authenticated user's ID against a column on the row. Avoid policies that evaluate to true for everyone, since those make the table public regardless of how the key is handled. Keep the service_role key, which bypasses RLS entirely, out of the app and on your server only. Done this way, the anon key shipping in the binary is fine, because RLS, not secrecy, is what stops a client from reading data it should not.
What to watch out for
The first trap is treating the anon key as a secret to hide, when it is designed to be public; effort spent obfuscating it is wasted if RLS is weak. The second is a policy set to true during development and never tightened, which leaves the table open to every client. The third is the service_role key accidentally bundled into the app, which bypasses RLS completely and exposes everything. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces the Supabase endpoint and any keys embedded in the build, so you can confirm only the anon key ships and then verify your RLS is doing the protecting. Fixing the RLS itself is work you do in Supabase.
What to take away
- App Store reviewers do not access your Supabase database directly; they use the app like any client.
- What they, and anyone with the anon key, can see is determined entirely by your Row Level Security.
- The anon key is public by design, so the protection is correct RLS, not hiding the key, and the service_role key must never ship in the app.
- Use a pre-submission scan such as PTKD.com to confirm which keys are in your binary, then verify your RLS scopes every table correctly.
