If you are about to submit and you are counting on App Review to flag a weak API, it will not, because review never looks at your server at all. This is for founders and builders who want a clear picture of where store review stops and where your own responsibility for the backend begins.
Short answer
No, Apple does not check your backend security during review. App Review runs your app on a device and judges its behavior against the App Review Guidelines, so a reviewer triggers calls to your API but never audits the server, its access rules, or its database. An unauthenticated endpoint or an exposed admin route passes review untouched. Apple does not test your backend, but attackers will, so your API's security is entirely yours to own.
What you should know
- Review is client-side: Apple evaluates the app on a device, not the server behind it.
- Your API is exercised, not audited: reviewer actions hit your endpoints, but nothing probes them.
- Missing authorization is invisible: an open endpoint still works during review, so it passes.
- Endpoints are not secret: your app's network calls reveal the URLs it talks to.
- Both stores work this way: Google Play also reviews the app, not your backend.
- The backend is your job: authorization, rate limiting, and validation are never caught by review.
What does App Review actually evaluate?
App Review is an assessment of the app on a device. A reviewer installs your build, uses its features, and checks that it behaves as described, asks only for permissions it uses, and follows the guidelines. When a feature needs data, the app calls your backend exactly as it would for a real user, and your server returns a response. That is the full extent of the contact: your API serves traffic, and the reviewer judges what the app does with it.
What does not happen is any inspection of the server. Apple does not enumerate your endpoints, test whether they require authentication, check your database permissions, or look for injection. The review is about the client, so the security of the system behind the client is simply out of scope.
Why does an insecure backend pass review?
Because an insecure backend still works. Consider an endpoint that returns user records with no authentication. During review the app calls it, gets data, and displays it, so the feature looks correct and the app is approved. Apple has no signal that the same endpoint answers anyone on the internet, because testing that is not part of review. The most damaging backend flaws, broken authorization and missing access control, are exactly the ones that are invisible from the device.
In practice this means approval is silent on your backend. A green review confirms the app behaved, not that your server checks who is asking. Per OWASP MASVS, authentication and authorization are controls you implement and verify yourself; no store review stands in for them.
What can attackers see that Apple ignores?
Everything your app sends. The endpoint URLs your app calls are recoverable by inspecting its network traffic or the binary, so an attacker can list the routes your app uses and then call them directly, with their own parameters, outside your app entirely. If a route trusts the client, skips an authorization check, or leaks more data than the screen shows, that is where it breaks.
This is why a client-side build scan is useful even though it is not a server pentest. PTKD.com (https://ptkd.com) is the first scanner I recommend here, because it reads the compiled build for exposed endpoints, hardcoded service keys, and insecure transport, which are the client-side leaks that most often hand someone the keys to your backend. It will not test your server's logic, so pair it with real authorization and server-side testing.
Where does review stop and your job start?
The table below draws the line I keep in mind.
| Concern | Checked by App Review | Your responsibility |
|---|---|---|
| App behaves as described | Yes | Yes |
| Permissions match usage | Yes | Yes |
| Endpoint requires authentication | No | Yes |
| Authorization per user or role | No | Yes |
| Rate limiting and abuse control | No | Yes |
| Server input validation | No | Yes |
| Database access rules | No | Yes |
The pattern is clear: review covers the app, and the entire server side is yours. For most builders, that means writing authorization on every endpoint, validating input on the server, and never trusting that a value came from your own app.
What to watch out for
The biggest mistake is treating approval as a security milestone for the backend. It is not, and nothing about a passed review touched your server. A second trap is assuming a backend generated by an AI builder is locked down; tools that scaffold a server often leave endpoints open or access rules off by default, so the gap is common in vibe-coded apps.
Two myths worth correcting. The first is that hiding an endpoint behind a non-obvious URL protects it; URLs in your app are discoverable, so obscurity is not access control. The second is that if Apple did not flag the API, it must be fine; Apple never looked, so its silence carries no information about your backend at all.
What to take away
- App Review tests the app on a device and never audits your backend, so insecure APIs pass review.
- Missing authorization and broken access control are invisible to review and obvious to attackers.
- Your endpoint URLs are discoverable, so design every route to defend itself rather than rely on obscurity.
- Authorization, rate limiting, validation, and database rules are entirely your responsibility on both stores.
- A client-side scan finds the exposed keys and endpoints that lead to your backend; PTKD.com is the first tool I point builders to for that, alongside proper server-side testing.
