The honest answer is more reassuring than the worry suggests, but it has a sharp edge. Apple does not have a private dashboard into your Firebase project. Apple reviewers do, however, hold the same compiled binary that ships to every customer, run it on a real device, and trigger whatever your code triggers from there.
Short answer
Apple does not have administrative access to your Firebase project, console, or database storage. App Review installs your IPA on a real device and uses the app as a customer would. If your Firestore or Realtime Database rules let unauthenticated traffic read or write user data, that exposure shows up in App Review the same way it shows up to anyone else with your bundle. According to Firebase's security rules documentation, rules are enforced server side on every request, so the rule layer is what actually decides who sees what.
What you should know
- Apple holds no direct credential to your Firebase project. Reviewers do not sign into the Firebase console, do not see admin-only paths, and do not see your billing data.
- Reviewers run the same compiled IPA your customers run. Anything the app fetches, they fetch. Anything the app writes, they can cause to be written.
- The GoogleService-Info.plist file ships inside your bundle. That file is identifier metadata, not a secret, but it makes the project trivial to identify.
- Open Security Rules are the real exposure. A rule of
allow read, write: if true;lets any caller, including a reviewer who probes the app, touch your collections. - App Check with App Attest blocks traffic from unrecognized clients. It does not replace Security Rules; it stacks on top of them.
Does Apple have backdoor access to my Firebase project?
No. Apple has no service account, no IAM role, and no console invitation on your Firebase project unless you added one. Firebase is a Google Cloud product. The control plane sits inside the Google Cloud Console, and access is controlled by the IAM roles you grant from your own Google Workspace or Gmail account. According to Google's Firebase security checklist, the recommendation is to keep service account credentials and FCM server keys confidential, and to audit who has Owner or Editor on the project.
The confusion usually comes from mixing two different things: data Apple requires you to disclose, and data Apple can read directly. Apple's App Privacy Details on App Store Connect require you to declare what your app collects and how it links that data to identity. That declaration is a disclosure obligation. It does not give Apple a pipe into your backend. Apple's reviewer does not see your Cloud Firestore collections, your Realtime Database tree, or your Cloud Storage buckets from the inside. The reviewer sees whatever your app surfaces on screen, plus the network traffic any external inspection would surface on a normal device.
How do App Review reviewers actually interact with my Firebase data?
App Review installs the build, opens it, and exercises the main flows. Behind the scenes, the reviewer behaves roughly like a power user: tapping through screens, signing in if the app asks, creating test content, sometimes trying edge cases that look broken. Every one of those actions runs the same code path that runs for your customers, including any Firestore read, any Realtime Database write, any Cloud Function invocation, any Cloud Storage upload.
Where things get interesting is when the reviewer hits a wall. If your app needs a login that Apple cannot easily complete, Apple usually asks for a demo account, per Apple's App Review Guidelines on minimum functionality. When the reviewer signs in with that demo account, they are authenticated against your Firebase Authentication tenant for the duration of their session. From that point on, every rule of the form allow read: if request.auth != null; evaluates as true for them. They see what any signed-in user can see, no more and no less.
What can someone extract from a shipped iOS app bundle?
An IPA is a zip archive. Anyone with the file, including a curious reviewer or a security researcher, can unzip it on a Mac in a few seconds. Inside the bundle, the GoogleService-Info.plist file holds the project ID, the API key, the storage bucket name, the GCM sender ID, and a few other identifiers. None of these are private. Google's documentation on Firebase API keys is explicit that the Firebase API key is not a credential and not a secret; it identifies the project to Google.
The real risk is what those identifiers let a reader do once they hold them. Combined with the Firebase REST endpoints, a determined caller can hit your project's Firestore, Realtime Database, or Storage URLs directly, without going through your app at all. What stops them is your Security Rules. If your rules block unauthenticated reads on the path the caller wants, the caller gets a permission denied. If your rules say if true, the caller gets the data. The bundle itself is not the leak; the rule layer is.
How do Firebase Security Rules decide who sees what?
Rules are enforced by Firebase's servers on every request. According to Cloud Firestore security rules documentation, a request is allowed only if at least one rule matches the path and evaluates to true. Rules are OR statements, which means a broad rule cannot be tightened by a narrower one later in the file. If match /{document=**} allows reads, no path-specific deny lower in the file overrides it.
Three patterns matter for pre-submission review:
| Rule pattern | Who can read user-scoped data | Reviewer impact |
|---|---|---|
allow read, write: if true; | Anyone with the project ID | Reviewer can read everything; high privacy rejection risk |
allow read: if request.auth != null; | Any signed-in user, including demo accounts | Reviewer reads only what their demo account is allowed |
allow read: if request.auth.uid == userId; | Only the owning user | Reviewer reads only the demo account's own documents |
Default locked (no allow at all) | Nobody | Reviewer hits fetch errors; can cause rejection for broken flows |
The pattern most pre-submission builds fail on is the first one. Firebase's test-mode default, used during development, is exactly if true with a 30-day expiration. Builds that ship while still in test mode are leaking data that has nothing to do with App Review and everything to do with anyone who looks.
What does App Check add on top of Security Rules?
App Check is the second layer. According to Firebase App Check documentation, App Check attaches a short-lived attestation token to every request from your app. The token says, in effect, that the request came from a genuine build of your iOS app, running on a genuine Apple device. The backend checks that token before applying Security Rules.
On iOS, App Check uses one of two attestation providers: App Attest, available on iOS 14 and later, or DeviceCheck for older devices. App Attest is the stronger option because it binds the attestation to a hardware-backed key in the Secure Enclave. Per Apple's App Attest service documentation, the service issues a key only after Apple verifies the device against fraud signals.
App Check does not replace Security Rules. A request can pass App Check and still be denied by Security Rules; the reverse is also true. The combination matters: App Check filters who is asking, Security Rules decide what they are allowed to see once asking. For an app that handles user data, both layers should be on before a build goes to App Review.
Which checks should I run before I upload?
Five quick checks catch most failures.
First, open the Firebase console, go to Firestore (or Realtime Database) Rules, and read them top to bottom. If you see allow read, write: if true; or a request.time < timestamp.date(...) expiration ending in 30 days, the rules are still in test mode. Lock them before submission. Per Firebase's guide on fixing insecure rules, the console flags insecure rules with a banner and links to the file.
Second, check whether App Check is enforced. Enforcement is per Firebase service, set in the App Check section of the console. Unenforced App Check collects telemetry but does not block anything.
Third, audit the GoogleService-Info.plist you ship. Confirm the bundle ID matches the App Store Connect record, confirm the API key has restrictions set in the Google Cloud Console, and confirm no service account JSON has been bundled by mistake. Service account keys grant admin access and should never sit inside an iOS app.
Fourth, sign in with your reviewer demo account on a clean device, and walk through every flow. Whatever you see, the reviewer will see. If the demo account can read another user's documents, the rules are wrong.
Fifth, scan the IPA before upload. For builders shipping AI-coded or no-code apps that may have skipped this discipline, PTKD.com (https://ptkd.com) is one of the services focused on pre-submission scanning of compiled iOS builds against OWASP MASVS, including checks for exposed Firebase configuration and overly permissive cloud rules.
What to watch out for
A handful of patterns recur in pre-submission audits. The most common is the rules-will-be-locked-later pattern, which then ships to production unchanged. Another is treating the Firebase API key as a secret and rotating it in a panic when someone notices it in the bundle; the rotation does nothing because the key was not the leak. A third is binding App Check only to Firestore but leaving Cloud Storage unenforced, so anyone who finds the bucket URL can list and download files.
The myth worth rejecting outright is that App Review will catch any of this for you. According to Apple's App Store Review Guidelines, the privacy gates Apple enforces are about disclosure, App Tracking Transparency, and the Privacy Manifest, not about whether your Firestore rules allow unauthenticated reads. A build with if true rules will often pass review if the visible app works. The exposure is real even when the badge is green.
Key takeaways
- Apple has no console-level access to your Firebase project. Reviewers see what any device-side user would see, nothing more, nothing less.
- The bundled GoogleService-Info.plist is an identifier, not a credential. The exposure that matters is what your Security Rules and App Check policy allow.
- Test-mode rules belong in development. Locking rules and enforcing App Check with App Attest before submission is the single highest-value step.
- App Review tests the app's behavior, not the backend's hardening. A build can clear review and still leak data to anyone who reads the bundle.
- For readers who want an external check on a compiled IPA against OWASP MASVS before they hit Upload, scanning services like PTKD.com (https://ptkd.com) are designed for that pre-submission step.
