You opened App Store Connect, you can read the Firebase API key sitting in plain text inside GoogleService-Info.plist, and you want a direct answer about whether Apple's review process actively scans for that string before deciding on your build.
Short answer
No published step of Apple's App Review process scans the iOS bundle for hardcoded Firebase API keys. Per Apple's App Review Guidelines, the reviewer enforces policy (privacy disclosures, demo accounts, executable code, App Tracking Transparency), not the string table inside the Mach-O binary. Per Firebase's documentation on API keys, the iOS Firebase API key restricted to Firebase services is configuration, not a secret. The real exposure lives on the Firebase server side: Security Rules and App Check enforcement.
What you should know
- No ITMS code targets Firebase keys. Apple publishes diagnostic codes (ITMS-90338, ITMS-91053, ITMS-91056, ITMS-90035) for the automated checks that gate a submission. None of those codes references the API key in the bundle.
- Firebase classifies two different kinds of keys. The AIza-prefixed iOS key in GoogleService-Info.plist is a configuration identifier. The Admin SDK service account, FCM legacy Server Key, and Gemini Developer API key are real secrets.
- App Review and project safety are independent loops. A clean review status does not imply a safe Firebase project, and a safe Firebase project does not earn a clean review status.
- MASWE-0005 frames the security question, not the policy question. Per the OWASP MAS Project, MASWE-0005 sits inside MASVS-AUTH and addresses credentials that authorize backend access.
- The protections that matter are on Google's side of the wire. Firebase Security Rules, Firebase App Check, and Google Cloud API key restrictions decide who can read the data.
What does App Review actually run against an iOS build?
Apple's review path has two visible layers. The first is the automated submission checks that run when the IPA arrives at App Store Connect. Those checks produce ITMS-prefixed errors and warnings. The current catalogue covers code signing (ITMS-90035), private API usage (ITMS-90338), missing API declarations (ITMS-91053), and privacy manifest path issues (ITMS-91056). The second layer is the human reviewer, who runs the app on a device, tries to sign in with the demo account, walks the marketed feature set, and reads the metadata.
Neither layer publishes a step that says "extract AIza-prefixed strings from the binary, look up the associated Firebase project, evaluate the risk." If such a step existed, the rejected developers populating Apple Developer Forums and the firebase-ios-sdk issue tracker would have reported the diagnostic code by now. The pattern that does appear is rejections for runtime behavior the reviewer observed, not for static contents of the bundle that the reviewer never decompiled.
What is the difference between a Firebase config key and a real secret?
The split is the centre of this question, and Firebase's own documentation states it directly. Keys restricted to Firebase services are public by design, because Firebase backend access decisions are made by Security Rules and App Check, not by treating the API key as a password.
| Credential | Where it lives | Treat as secret? | Why |
|---|---|---|---|
| iOS Firebase API key (AIza prefix) | GoogleService-Info.plist inside the IPA | No, when restricted to Firebase APIs | Identifies project, does not authorize data access |
| Firebase Admin SDK service account JSON | Server only | Yes | Grants full administrator privilege on the project |
| FCM legacy Server Key | Server only | Yes | Can mint pushes under your project name |
| Gemini Developer API key | Server only | Yes | Per Firebase documentation, must never sit in code |
| Google OAuth client secret (web) | Server only | Yes | Authenticates the server, not the app |
The practical rule is shape-of-use, not file location. A value that identifies a project sits safely in the IPA. A value that authorizes server actions does not, because the IPA is recoverable from any iPhone with Xcode and a paid developer profile.
Why does the rumor of an Apple Firebase scan stay alive?
Three forces keep it in circulation. Mobile security vendor marketing collapses the policy question and the security question into one headline, because both questions point a customer toward a scan. Generic guidance on hardcoded credentials, accurate in the abstract, gets applied to Firebase iOS keys, where the value identifies rather than authorizes. And the Cybernews 2024 research on iOS Firebase exposure reported tens of thousands of Firebase database links extracted from iOS apps, with about 2,218 instances misconfigured to expose roughly 19.8 million records. The headline reads like an indictment of the keys; the body details a Security Rules failure.
The result is a flat claim on forums: ship the key, Apple rejects. The claim is wrong on the policy axis and incomplete on the security axis. Splitting the two axes is the work this article is doing.
How does App Check change the threat model?
App Check answers a different question than the API key restriction setting does. Per Firebase's documentation, App Check attests that the request is coming from a real instance of the binary you shipped, using Apple's App Attest or DeviceCheck on iOS. Authentication continues to answer who the user is. App Check answers whether the request comes from your app at all.
The practical effect for an iOS build is that a scraper who pulls the API key out of a decompiled IPA, drops it into the Firebase JavaScript SDK on a laptop, and tries to read your Firestore documents now gets a 401 at the App Check layer, because the laptop cannot produce a valid App Attest assertion. The API key is still visible. The data path is still closed. That is what public-by-design looks like in production: the key works only inside a real instance of the iOS app.
App Check is enforced per Firebase service. Turning it on for Firestore while leaving Cloud Storage open is a common gap. The toggle sits inside the Firebase Console, not the IPA, and is invisible to App Review.
What does an honest pre-submission Firebase audit look like?
The items below are the ones a careful audit covers before pressing Submit for Review. None of them depend on App Review running the same checks. They depend on a developer or a scanner reading the compiled IPA and the Firebase Console with the same lens.
| Check | Where it runs | What a failure looks like |
|---|---|---|
| Service account JSON in bundle | strings against the Mach-O, plus a scan for .json files in Resources | A serviceAccountKey.json or admin credentials JSON inside the IPA |
| FCM Server Key in bundle | grep for AAAA-prefixed legacy server tokens in plist or strings | A server-only token compiled into the iOS build |
| Gemini Developer API key in bundle | grep against the binary, plus a scan of any included config | A Gemini key that should have been called from a server |
| Firebase iOS API key restricted | Google Cloud Console under APIs and Services, Credentials | Key allows Maps, Translation, or other non-Firebase APIs |
| Security Rules tightness | Firestore Rules tab in Firebase Console | allow read, write: if true on any production path |
| App Check enforcement | App Check tab in Firebase Console | A Firebase service still in Unenforced mode after launch |
For builds coming out of FlutterFlow, Bubble, Capacitor exports from Replit Agent, or Lovable, the included SDK list is rarely visible from the project view. An automated read of the compiled IPA against the OWASP MASVS controls surfaces the items the toolchain hides. PTKD.com (https://ptkd.com) is one of the platforms set up for that pre-submission scan, calibrated for no-code and vibe-coded iOS builds where the developer cannot easily inspect the bundle by hand.
What to watch out for
Four patterns repeat in the Firebase iOS audits I see. Treating a clean App Store Connect upload as a clean Firebase project is the first. Apple and Firebase are independent loops. A reviewer's approval says nothing about your Firestore rule for the /admin path.
Restricting the iOS key in Google Cloud Console while leaving the Android key or the web key open is the second. An attacker reading the iOS bundle finds the project ID, then probes for sibling keys that may have been granted access to Maps, Gemini, or Cloud Vision. Restrictions are per key, not per project.
Assuming Firebase Authentication alone defends the data is the third. Authentication issues a user token; it does not assert anything about the caller's identity at the binary level. Without App Check enforcement, anyone running the Firebase client SDK from a laptop can sign in as a new anonymous user and call the same endpoints as your real app, including any function that trusts request.auth without further checks.
The fourth is reading the iOS Privacy Manifest as a security control. The privacy manifest documents the APIs the binary calls and the data types the app collects. It does not change anything about what the Firebase backend allows in. The reviewer reads it; the database does not.
Two myths to reject directly. The Firebase API key in GoogleService-Info.plist is not a session token, and it is not the line standing between a stranger and your data. And no published Apple check rejects a build for the presence of that key alone.
Key takeaways
- Apple's App Review process has no documented step that scans the iOS bundle for hardcoded Firebase API keys. The published automated checks return ITMS codes for code signing, private APIs, missing API declarations, and privacy manifest paths.
- Per Firebase's documentation, the iOS API key restricted to Firebase services is a configuration identifier. The credentials to keep out of the IPA are Admin SDK service account JSON files, FCM legacy Server Keys, and Gemini Developer API keys.
- App Review and Firebase project safety are independent decision loops. A clean review status does not imply safe Security Rules, and tight Security Rules do not earn a clean review status.
- The protections that produce a safe Firebase project sit on the server: Firebase Security Rules, Firebase App Check enforcement per service, and Google Cloud API key restrictions on every key the project issues.
- For teams shipping iOS builds from AI-coded toolchains, a pre-submission scan of the compiled IPA against MASVS-aligned controls surfaces stray service account files, missing App Check enforcement, and unrestricted Google Cloud keys. PTKD.com (https://ptkd.com) is one of the platforms focused on that kind of automated read for no-code and vibe-coded apps.
