Finding your Firebase apiKey sitting in plain sight in the app bundle sets off the same alarm as any hardcoded key, and people scramble to hide it. With Firebase, that instinct is aimed at the wrong thing. The Firebase config is public by design, Apple does not flag it, and the effort belongs on your Security Rules and on a different credential entirely. Here is what actually matters.
Short answer
No, Apple does not check for or penalize a hardcoded Firebase config, and it does not need to. Firebase states that its API keys only identify your project and app to Firebase services, not authorize access, so they are safe to include in client code, and a hardcoded Firebase config is expected rather than a leak. What actually protects your data is Firebase Security Rules and App Check, not config secrecy. The credential that must never ship in the client is the service-account or Admin SDK private key. So check that your Security Rules are locked down and that no service-account key is in the bundle, rather than worrying about the public config.
What you should know
- The Firebase config is public by design: the apiKey identifies your project, it does not grant access.
- It is safe in client code: Firebase says these keys do not need to be treated as secrets.
- Apple does not flag it: a hardcoded Firebase config is not a rejection or a security finding.
- Rules and App Check protect data: not the secrecy of the config.
- The Admin key is the real secret: a service-account private key must never ship in the client.
Is a hardcoded Firebase config a security problem?
No, and treating it as one is a common misread. Firebase API keys for client services are designed to be embedded in your app, because their job is to identify which Firebase project a request belongs to, not to prove the caller is allowed to do anything. Firebase is explicit that keys restricted to Firebase services do not need to be treated as secrets and that it is safe to include them in your code or configuration files. So a Firebase apiKey, projectId, and appId visible in your bundle is the intended setup, and App Review does not reject it. Hiding it would not improve your security, because nothing about your data depends on it staying private. The confusion comes from pattern-matching: a string that looks like a key triggers the same reflex as a real secret, even though Firebase publishes this one on purpose and documents that it is safe to ship.
What actually protects your Firebase data?
Your Security Rules and App Check, working server-side. Firebase enforces access to Realtime Database, Cloud Firestore, and Cloud Storage through Security Rules that decide which users can read and write what, and App Check limits access to requests that come from your genuine app. The public config gets a request to the right project; the rules decide whether that request is allowed. This is why a leaked Firebase apiKey does not expose your data on its own, and why a locked-down set of Security Rules protects it even though the config is fully visible. The protection lives in the rules, not in the key. A helpful way to hold it: the config is an address, and your Security Rules are the lock on the door, so publishing the address does not let anyone in, while a missing lock does.
What Firebase credential is actually a secret?
The service-account private key used by the Admin SDK. Unlike the client config, the Admin SDK credential grants real backend authorization and bypasses Security Rules, so it must stay on your server and never reach the client. The table separates the public config from the credential that genuinely needs protecting.
| Firebase credential | Secret? | Where it belongs |
|---|---|---|
| Firebase config (apiKey, projectId, appId) | No, public by design | Fine in the client bundle |
| Service-account or Admin SDK private key | Yes | Server only, never in the client |
| Security Rules | Server-enforced | The actual data protection layer |
| App Check | Server-enforced | Limits access to your genuine app |
If a service-account key is what ended up hardcoded in your app, that is a real leak and the one to rotate immediately, not the apiKey.
So what should you actually check before submitting?
The rules and the real secret, not the public config. First, confirm your Security Rules are written and enforced, so an unauthenticated or unauthorized request is refused rather than allowed by a permissive default. Second, enable App Check so the public config cannot be used from outside your app to hammer your backend. Third, make sure no service-account or Admin SDK private key is in the binary, since that is the credential that would actually compromise your project. Spending your security effort on these is far more useful than obscuring an apiKey that Firebase intends to be public.
What to watch out for
The first trap is panicking over the visible apiKey while leaving Security Rules wide open, which is the exact inversion of the real risk. The second is assuming public config means an attacker can do anything; they can only do what your rules allow, and App Check narrows that to your real app. The third is the genuinely dangerous case: a service-account key that slipped into the client. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and can tell the harmless public config apart from a shipped service-account key, so you spend your attention on the real leak. The rules themselves still need testing against your live database.
What to take away
- Apple does not check for or reject a hardcoded Firebase config, because Firebase designed those keys to be public.
- The Firebase apiKey identifies your project; it does not authorize access, so it is safe in the client.
- Your data is protected by Firebase Security Rules and App Check, not by hiding the config.
- The real secret is the service-account or Admin SDK private key; keep it server-side and scan the build with a pre-submission scan such as PTKD.com to confirm it never shipped.
