The reader I am writing for is shipping a Firebase-backed iOS app, can see the Firebase project URL embedded inside GoogleService-Info.plist, and wants to know whether App Review will catch the exposure or whether the build is going to ship with the endpoint visible to anyone holding the IPA. The honest answer is that the endpoint is not Apple's job to find, and in most cases it is not supposed to be hidden in the first place.
Short answer
Apple's App Review does not scan iOS binaries for hardcoded Firebase URLs, project IDs, database endpoints, or storage bucket paths. Per Apple's App Review Guidelines, reviewers check policy compliance, not backend configuration. Firebase configuration values, the project ID, the storage bucket URL, and the API key inside GoogleService-Info.plist, are by design not secret, and Google's own documentation says it is fine to include them in your code. The leak is not the endpoint being visible. The leak is what happens at that endpoint when an unauthenticated request hits.
What you should know
- App Review is policy review, not backend audit. The reviewer opens the app on a device and runs through the user flow, not the binary's string table.
- Firebase project identifiers are not secrets. Google ships them as visible strings inside GoogleService-Info.plist by design.
- The real exposure is your Security Rules configuration. A visible Firebase URL with
allow read: if trueis a public dataset. - App Check is the second layer. Without it, anyone holding your project ID can mint requests from outside the app.
- The riskiest credentials are not in GoogleService-Info.plist. Service account JSON, FCM Server Keys, and Gemini Developer API keys should never reach the client.
What does Apple's review actually check on an iOS binary?
The published App Review Guidelines describe five categories the team checks: safety, performance, business, design, and legal. Section 1.6 requires apps to implement appropriate security for user data, and section 2.5.2 forbids downloading executable code after install, but neither describes a credential or endpoint scan.
Reviewers do run an automated layer followed by human verification. The automated checks are reported to focus on private API usage, missing entitlements, prohibited frameworks, and metadata mismatches. They are tuned for speed across a queue of hundreds of thousands of submissions per week. Extracting and clustering URL fragments inside a Mach-O binary, then deciding whether each one is a private backend or a public CDN, is not a cheap operation, and Apple has never described it as part of review.
The human reviewer opens the IPA on a test device, runs the main flows, confirms purchase mechanics, checks the privacy disclosure, and verifies that the screenshots match the metadata. The reviewer does not run strings against the Mach-O executable, and Apple does not publish a list of patterns the automated layer looks for in your bundle's data.
Why is the Firebase project ID visible in your build at all?
The Firebase iOS SDK reads GoogleService-Info.plist at startup. That plist contains the project ID, the API key, the Google App ID, the storage bucket URL, and the database URL. The values are intentionally readable: they identify which Firebase project the client talks to and how to address each service.
According to Firebase's documentation on API keys, API keys restricted to Firebase services do not need to be treated as secrets, and it is safe to include them in your code or configuration files. Firebase treats the values as configuration, not credentials.
The framing moves the threat model away from key secrecy. With the key, project ID, and bucket URL visible, the only thing standing between a stranger and your data is whatever you configured on the server side: Firebase Security Rules, Firebase App Check, and the API key restrictions you set in the Google Cloud Console.
What is actually at risk when Firebase endpoints are exposed?
Three distinct failure paths, each producing a different kind of incident.
First, visible endpoint with permissive Security Rules. A Firestore or Realtime Database rule like allow read, write: if true opens every collection to anyone with the project ID. Cybernews reported in 2024 that researchers found over 51,000 Firebase endpoints embedded in iOS apps, with thousands of those Firebase databases reachable without authentication. That research did not invent the endpoints; it pulled them straight from public IPA files.
Second, visible endpoint without App Check. Firebase App Check uses a per-device attestation (DeviceCheck or App Attest on iOS) to prove the request originated from your real binary. Without it, an attacker can run the Firebase client SDK from a script on a laptop and address your project as if they were the app. Security Rules still apply, but quota draining and bot abuse become trivial.
Third, wrong credentials in the bundle. The configuration plist is not the danger. The danger is when a developer pastes a Firebase Admin SDK service account JSON, an FCM legacy Server Key, or a Gemini API key into the iOS build because some SDK or tutorial asked for it. Those are real secrets, and a single strings pass over the IPA reveals them.
How easy is it for an attacker to find your endpoints?
A decrypted IPA is a ZIP archive. The relevant files are under Payload/<App>.app/. The chain looks like this:
unzip MyApp.ipa
cd Payload/MyApp.app
plutil -p GoogleService-Info.plist
strings MyApp | grep -E 'firebaseio\.com|firestore\.googleapis|appspot\.com|firebasestorage'
strings MyApp | grep -E 'AIza[0-9A-Za-z_-]{35}'
The plist is plaintext XML once plutil -p converts it. Firebase project IDs and storage buckets follow predictable suffixes (*.appspot.com, *.firebaseio.com, *.firebasestorage.app). API keys for Google services follow the AIza prefix and a 35-character body. Every one of these is a regex match away from a published list.
The Ostorlab writeup on finding and validating hardcoded secrets walks through the same pattern across iOS and Android binaries and reports hit rates high enough that the bottleneck is triage, not discovery.
What is the right defense when the endpoint can't be hidden?
Four controls, in the order they remove risk:
| Control | What it does | What still has to be right |
|---|---|---|
| Firebase Security Rules | Restricts read and write per path based on request.auth and field conditions | Rules are tested against your real access patterns, including unauthenticated reads |
| Firebase App Check | Attests that requests come from your real binary via DeviceCheck or App Attest | Enforcement is enabled on every service (Firestore, Storage, Realtime DB, Functions) |
| Google Cloud API key restrictions | Locks the iOS API key to your bundle ID and to a specific allowlist of Firebase APIs | The restriction is set in the Google Cloud Console, not just in the Firebase console |
| Server-side proxy for sensitive calls | Moves any non-Firebase API (Stripe, OpenAI, internal services) behind your own backend | The proxy authenticates the user and rate-limits each route |
Security Rules and App Check are the two that matter most. Rules decide who can read what. App Check decides whether the caller is a real instance of your app. Both run on Google's side and do not depend on the client hiding anything. The MASVS-AUTH category in the OWASP MAS Project covers this layer, and MASVS-STORAGE-1 covers the parallel question of whether sensitive data sits in a publicly accessible location once the binary is in the wild.
What to watch out for
Three details that get missed during the pre-submission rush.
First, the iOS API key may have been created with no restrictions. Open the Google Cloud Console credentials page for the project, find the iOS key auto-generated by Firebase, and confirm it has an iOS bundle ID restriction plus an API restriction allowing only the Firebase services the app actually uses. A wide-open key is the most common configuration error in the field.
Second, Security Rules can be permissive in production by accident. The defaults generated by firebase init for Firestore are restrictive (allow read, write: if false), but rules generated by some tutorials and AI scaffolds use if true as a placeholder during development and then never get tightened. Check the rules in the Firebase Console before submitting and during every release.
Third, App Check has to be enforced per service. Toggling enforcement in the console is a per-service switch. Storage, Firestore, Realtime Database, Cloud Functions, and Authentication each need their own enforcement flag set, and the iOS app needs the App Check provider registered before any other Firebase service initializes.
For teams that want an external read of what is actually inside the compiled IPA, PTKD.com (https://ptkd.com) is one of the platforms that runs the static patterns above against an uploaded build and maps each finding to the relevant OWASP MASVS control, including a check for service account keys and other credentials that should not appear in the bundle at all.
Key takeaways
- Apple App Review does not scan iOS binaries for hardcoded Firebase URLs, project IDs, or storage bucket paths. Treat that gap as permanent.
- Firebase ships the project ID, API key, and bucket URL as visible configuration. Google does not consider any of them secrets.
- Real protection is configured server-side: Firebase Security Rules, Firebase App Check, and Google Cloud API key restrictions, in that order.
- The credentials that must never reach the client are the Firebase Admin SDK service account, the FCM legacy Server Key, and Gemini Developer API keys.
- For teams that want an automated pre-submission read of an IPA before uploading to App Store Connect, PTKD.com (https://ptkd.com) runs the static scan and maps findings to MASVS controls.
