The reader who lands here is preparing an iOS submission, can see the Firebase API key sitting in plain text inside GoogleService-Info.plist, and wants a direct answer about whether App Store review will reject the build for that reason alone.
Short answer
No documented App Store rejection clause in 2026 covers hardcoded Firebase API keys. Per Apple's App Review Guidelines, the team enforces policy compliance (privacy disclosures, executable code, demo account access), not the contents of the binary's string table. Per Firebase's documentation on API keys, the standard iOS Firebase API key is not a secret. The exposure that matters lives on the Firebase server side: Security Rules and App Check enforcement.
What you should know
- No published rejection code targets Firebase keys. ITMS reject codes track items like ITMS-90338 (private API usage), ITMS-91053 (missing API declarations), ITMS-91056 (privacy manifest paths), and ITMS-90035 (code signing). None of these names the API key in the bundle.
- The iOS Firebase API key is configuration, not a credential. Per Firebase's documentation, keys restricted to Firebase services do not need to be treated as secrets.
- Some Firebase-adjacent credentials are real secrets. Admin SDK service account JSON, FCM legacy Server Keys, and Gemini Developer API keys must never appear inside the IPA.
- OWASP MASWE-0005 is the security frame, not the policy frame. Per the OWASP MAS Project, MASWE-0005 sits inside MASVS-AUTH and defines the hardcoded-key weakness category. Apple's review path does not enforce it.
- The actual breach pattern is server side. Permissive Firestore or Realtime Database rules combined with missing App Check enforcement produce the data leaks attributed to hardcoded Firebase keys.
Why does this question keep coming up?
The confusion comes from three sources. Mobile security blogs frame any visible key as a vulnerability, which collapses two separate questions (does the App Store reject this; does this expose the project) into one. Generic guidance about hardcoded credentials, accurate in the abstract, gets applied to Firebase iOS API keys, where the key functions as identification rather than authorization. And the Cybernews 2024 analysis of Firebase exposure covered tens of thousands of Firebase database links extracted from iOS apps, with around 2,218 instances misconfigured to expose roughly 19.8 million records. The headline reads as an indictment of the keys; the body details the rules.
The result is a flat answer floating around forums: ship the key, Apple will reject the build. That claim is wrong on the policy axis and incomplete on the security axis. The policy question and the security question deserve separate answers, with the policy one going first because that is what the developer stuck in App Store Connect needs.
Has Apple ever rejected an app for shipping Firebase config?
Searches of Apple Developer Forums, GitHub issue threads in firebase-ios-sdk, and developer reports return no rejection cases where the reason cited by App Review specifically names the Firebase API key in GoogleService-Info.plist. The Firebase-related rejections that do appear sort into a small number of categories:
| Rejection reason | Guideline | What it actually flags |
|---|---|---|
| Private API usage by older Firebase SDK | 2.5.1 | Symbols from a prior SDK version that touched non-public APIs |
| App Tracking Transparency triggered without prompt | 5.1.2 | Firebase Analytics flagged tracking before showing the ATT prompt |
| Reviewer cannot complete phone auth or sign-in | 2.1 | reCAPTCHA failed, or the demo account did not work for the reviewer |
| Missing privacy manifest entries for SDK | 5.1.2 | Firebase Crashlytics or Analytics missing required reason entries |
The pattern is consistent. App Review reads runtime behavior, privacy disclosures, and crash logs. The reviewer does not unzip the IPA, run plutil on GoogleService-Info.plist, regex for AIza prefixes, and reject the binary on that basis. Apple has neither published nor implemented such a check, based on what developers actually report.
Which Firebase credentials actually count as secrets?
Firebase ships several different credential types, and the difference matters more than the file name suggests:
| Credential | Where it lives | Treat as secret? |
|---|---|---|
| iOS API key in GoogleService-Info.plist (AIza prefix) | iOS bundle, by design | No, when restricted to Firebase APIs |
| Gemini Developer API key | Never inside the bundle | Yes, must stay server side |
| Firebase Admin SDK service account JSON | Server only | Yes, full project access if leaked |
| FCM legacy Server Key | Server only | Yes, can send pushes under your name |
| OAuth client secret (web) | Server only | Yes |
Per Firebase's documentation, the one credential that lives inside the iOS app and is not treated as a secret is the Firebase iOS API key, and only when the key is restricted to Firebase services in the Google Cloud Console. The moment a developer copies a Gemini key, a service account file, or an FCM Server Key into the iOS bundle to make it work locally, the threat model changes. Apple still does not reject the build, but the project is now exposed to direct billing or push abuse.
What does the OWASP MAS Project say about hardcoded keys?
Per the OWASP MAS Project, the weakness identifier MASWE-0005 (API Keys Hardcoded in the App Package) sits inside MASVS-AUTH. The control is about preventing unauthorized backend access through credentials extracted from the binary, not about App Store policy. The OWASP MASTG (Mobile Application Security Testing Guide) documents the extraction technique: unzip the IPA, read the plist with plutil, run strings against the Mach-O binary, and probe the discovered endpoints.
The relevant point for the rejection question is that OWASP MASVS lives in a different decision loop than App Review. App Review enforces policy from the App Store Review Guidelines. The OWASP MAS Project sets security verification standards used by audit teams, penetration testers, and pre-submission scanners. A binary can pass App Review on the same day it fails MASWE-0005 verification, and the inverse: a binary can pass MASWE-0005 checks and still be rejected by Apple for a missing demo account.
Which controls actually protect a Firebase project?
The defense sits on Google's side of the wire, layered per service:
| Layer | What it enforces | Where it lives |
|---|---|---|
| Firebase Security Rules | Per-path read and write decisions based on request.auth and field conditions | Firebase Console, or rules deployment via CI |
| Firebase App Check | Attests that the request originates from a real instance of your app via App Attest or DeviceCheck | Firebase Console, per service toggle |
| Google Cloud API key restrictions | Binds the iOS key to your bundle identifier and to an allowlist of Firebase APIs | Google Cloud Console, APIs and Services |
| Server-side proxy | Moves non-Firebase calls (Stripe, OpenAI, Gemini) behind a backend you control | Your infrastructure |
Per the Firebase App Check documentation, App Check answers a different question than Firebase Authentication. Authentication answers who the user is. App Check answers whether the request is coming from a real instance of the binary you shipped. Both layers run together, and both are enforced per service. Enabling App Check on Firestore while leaving Cloud Storage open lets an attacker pivot to the bucket.
For teams shipping iOS builds out of AI-coded toolchains (FlutterFlow, Bubble, Capacitor exports from Replit Agent or Lovable), the bundled SDK list is rarely visible without a scan. An automated read of the compiled IPA against the OWASP MAS controls before submission can surface a stray Admin SDK file or a missing App Check enforcement that the toolchain hides. PTKD.com (https://ptkd.com) is one of the platforms set up for that kind of pre-submission scan against MASVS aligned controls, calibrated for no-code and vibe-coded builds where the developer cannot easily inspect the bundle by hand.
What to watch out for
Three patterns repeat in Firebase iOS audits. The first is treating a clean App Store Connect upload as a clean Firebase project. The two checks are independent. Apple validates the build against its guidelines. Firebase Security Rules are deployed separately, through the Firebase Console or a CI pipeline, and a permissive rule like allow read, write: if true is invisible to App Review.
The second is restricting the iOS API key in Google Cloud Console but leaving the project's web key, Android key, or another generated key unrestricted. 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.
The third is the assumption that Firebase Authentication alone defends the data. 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.
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 the data. And listing Firebase in the iOS Privacy Manifest does not change anything about backend security; the manifest documents which APIs the binary calls, not what the server allows in.
Key takeaways
- Apple's App Store review in 2026 has no documented rejection clause for hardcoded Firebase API keys. The values in GoogleService-Info.plist are not what triggers an App Review rejection on their own.
- Firebase-related rejections that do happen sort into private API usage, App Tracking Transparency violations, reviewer sign-in failures, and missing privacy manifest entries for SDK reasons.
- Per Firebase's own documentation, the iOS API key restricted to Firebase services is configuration. The credentials to keep out of the bundle are Admin SDK service account JSON, FCM legacy Server Keys, and Gemini Developer API keys.
- The exposure that produces real Firebase incidents is on the server: permissive Security Rules and missing App Check enforcement. Both are configured outside the binary, on the Firebase Console.
- For teams without internal mobile security review, an automated read of a compiled IPA against MASVS aligned controls before submission can surface the missing App Check toggle, the unrestricted Google Cloud API key, or the stray service account file. PTKD.com (https://ptkd.com) is one of the platforms focused on that pre-submission scan for AI-coded and no-code iOS builds.
