You submitted the app, the backend is connected, and now you are wondering whether App Review will catch an open Supabase table or a loose Firebase rule before it ships. The honest answer is reassuring in one direction and uncomfortable in the other: Apple will not audit your backend rules, which also means it will not save you from a weak one.
Short answer
No, App Review does not check your Supabase Row Level Security or Firebase Security Rules. Apple's Guideline 2.1 asks you to keep your back-end service on during review so the app is testable, and reviewers exercise the app against that live backend. They do not log into your database or inspect your server-side authorization. Apple reviews the binary and the app's observable behavior, so a misconfigured RLS policy passes review as long as the app appears to work.
What you should know
- App Review needs your backend live: Guideline 2.1 requires the back-end service on, with demo credentials, so the app is testable.
- It checks behavior, not configuration: reviewers tap through the app; they do not read your RLS policies or Firebase rules.
- RLS is off by default: in Supabase, every table is reachable by the public anon key until you enable Row Level Security.
- Firebase rules are not automatic: they are a developer-configured authorization layer you must write, test, and deploy.
- Passing review is not a backend audit: a clean approval says nothing about whether your database is locked down.
What does App Review actually check on your backend?
It checks that the backend is reachable and that the app works against it, not that the backend is secure. Apple's Guideline 2.1 explicitly tells you to turn on your back-end service and provide a demo account so a reviewer can sign in and use the app. From there the review is about behavior: does the app crash, does a feature load, does the content match the description, does the app collect data it did not declare. A common rejection in this area is a backend that returns errors because it does not recognize Apple's review IP range, which makes the app look broken. That is a functionality check, not a security audit.
Where is the line between the binary and your backend?
The line is observability. App Review works as a black box that sees two things: the binary you upload and the behavior that binary produces against your live services. It reads the compiled app for declared permissions, linked SDKs, and transport settings, and it watches what the app does on screen and over the network. Your server-side authorization, the RLS policy or Firebase rule that decides whether a request is allowed, sits on the other side of that line, on infrastructure Apple never touches.
| Layer | Reviewed by App Review? | Who secures it |
|---|---|---|
| App binary (permissions, SDKs, transport, stored secrets) | Yes, read from the upload | You, verified by a scan |
| App behavior on device and over the network | Yes, observed during review | You |
| Backend uptime and basic functionality | Yes, must be live per Guideline 2.1 | You |
| Supabase RLS or Firebase Security Rules | No | You, tested live |
Keep this boundary in mind: anything inside the binary or visible in behavior can be reviewed, and anything that lives only on your server cannot. For the related question of whether Apple reads keys inside the binary, see does App Review check API keys.
So who is responsible for your Supabase or Firebase rules?
You are, fully. Firebase documents Security Rules as a developer-configured authorization layer that you write, test in an emulator, and deploy, not as automatic protection. Supabase Row Level Security is off by default, so until you enable it per table and write policies, the public anon key can read or write data it should not. Neither platform turns this on for you, and neither store reviews it. The practical consequence is that the strongest protection for your data is configured and tested by you, before and after submission, independent of whether the app passes review.
Can a reviewer still notice a backend problem?
Sometimes, but only when it surfaces in behavior. If a misconfigured backend leaks another user's data into the app's interface, or the app sends data over plain HTTP that App Transport Security would flag, a reviewer can see that and reject under the data and security guidelines. Apple's safety rules require apps to implement appropriate measures to prevent unauthorized access to user information. The limit is that this is incidental: the reviewer notices a visible symptom, not the underlying RLS gap. A backend that is wide open but never exposes the wrong data on screen during a short review will pass, which is exactly why a clean approval is not evidence that the rules are correct.
What to watch out for
The trap is false comfort. A submitted app that gets approved feels validated, and it is easy to read that approval as a security pass, but App Review never tested your authorization layer. Treat the boundary as a division of labor: Apple checks the binary and behavior, you secure the backend. A pre-submission scan such as PTKD.com (https://ptkd.com) covers the binary side, reading the compiled APK, AAB, or IPA against OWASP MASVS for exposed keys, weak transport, and risky permissions, while your Supabase or Firebase rules need their own live tests where you confirm an unauthenticated request is actually refused. The two together close the gap that neither App Review nor a single tool closes alone.
What to take away
- App Review does not inspect your Supabase RLS or Firebase rules; Guideline 2.1 only requires the backend to be live so the app is testable.
- The boundary is observability: Apple reviews the binary and behavior, not server-side authorization it cannot see.
- Backend security is yours to own; RLS is off by default in Supabase, and Firebase rules protect nothing until you write and deploy them.
- Pair a binary-side pre-submission scan such as PTKD.com with your own live tests of the backend rules, because a clean approval is not proof your database is locked down.
