Yes, it is safe to put your Firebase config, including the apiKey, in a React Native app, because that config is an identifier for your Firebase project, not a secret credential. Firebase is designed for the config to live in client apps, and your data is protected not by hiding the config but by Firebase Security Rules, Authentication, and App Check. The key distinction is that the Web API key in your config is public by design, while a service account or Admin SDK private key is a real secret that must never ship in the app. So include the config, lock down your Security Rules, and keep the true secrets on your server.
Short answer
The Firebase config, apiKey included, is safe in a React Native app because it identifies your project rather than authorizing access. Per Firebase's API keys documentation, these keys are not secrets and are meant to be included in client code, with access controlled elsewhere. Per Firebase's Security Rules, your rules decide who can read and write your data, so they, along with Authentication and App Check, are your real protection. What must never appear in the app is a service account or Admin SDK private key, which bypasses rules and grants full access. Include the config, write strict rules, and keep secrets server-side.
Is it safe? Why the config is public by design
It is safe, and the reason is that the Firebase config is not a secret to begin with. The values in your config, the apiKey, project ID, app ID, and the various domain and sender fields, together identify which Firebase project your app talks to. They are analogous to a public address, not a password, so exposing them tells an observer which project you use but does not, by itself, grant them any access to your data. Firebase expects this config to be present in client apps, including web and React Native.
This surprises people because one of the fields is called apiKey, which sounds like a secret. In Firebase, that Web API key is an identifier used to route your app's requests to the right project, and Firebase's own documentation states it does not need to be treated as a secret. Security is enforced by other mechanisms, not by keeping the config hidden. So the correct mental model is that the config being visible is expected and fine, and your effort belongs on the controls that actually decide who can do what.
API keys versus secret keys in Firebase
The distinction that resolves this question is between the client API key and true server secrets. The Firebase Web API key in your app config is a client identifier: safe to include, not a credential that grants privileges on its own, and governed by your Security Rules and other controls. Including it in React Native is expected, not a mistake, and it is the same value across every install of your app.
A secret key in the Firebase world is something entirely different: a service account credential, typically the Admin SDK private key JSON, which authenticates privileged server-side access and bypasses your Security Rules. That key must live only on a server you control and must never be bundled into your app, committed to your repository, or exposed, because anyone who obtains it has full administrative access to your project's data. So when you ask whether Firebase keys are safe in the client, the answer depends entirely on which key: the client config apiKey is safe, and the service account key is a serious secret that never ships.
Security Rules: what actually protects your data
Because the config is public, Firebase Security Rules are what actually protect your data, and getting them right is the real work. Rules on Cloud Firestore, the Realtime Database, and Cloud Storage decide, per request, who can read or write which data, evaluated on Firebase's servers rather than in your app. With strict rules, even though anyone can see your config and send requests to your project, they can only access the data your rules permit, which is what makes the public config safe.
The common failure is not an exposed config but weak rules. A project left in test mode, or with rules that allow reads and writes to anyone, exposes all its data regardless of how well the config is hidden, because the rules are the gate and the gate is open. Write rules that deny by default and grant access based on Firebase Authentication, so that users can only reach their own data, and test them. If your Firebase data has ever been publicly readable, the fix is your rules, not concealing the config.
App Check and API key restrictions
Beyond rules, two defense-in-depth measures harden a Firebase app further. App Check helps ensure that requests to your Firebase resources come from your genuine, untampered app rather than from a script or a cloned client, by attesting the app's authenticity, which reduces abuse of your backend even though your config is public. It is worth enabling for a production app, since it raises the bar against automated misuse.
You can also restrict the Web API key in the Google Cloud console, limiting which apps and which APIs may use it, so that even though the key is visible, its use is scoped. These measures do not replace Security Rules, which remain the core protection for your data, but they add layers that reduce abuse and misuse. Think of the arrangement as rules and Authentication deciding who can access data, App Check confirming the request comes from your app, and key restrictions narrowing where the key can be used, together forming a defense-in-depth posture around a config that is public by design.
The real mistake to avoid
The genuine mistakes here are not putting the config in the app, but two others. The first is relying on hidden config as your security, then leaving Security Rules weak, which exposes your data no matter how the config is stored. If you took away one thing, it would be that hiding the config protects nothing and correct rules protect everything, so invest accordingly.
The second, more serious mistake is shipping a true secret in the app, above all a service account or Admin SDK key. That does grant full access, and unlike the config it is genuinely dangerous in the client, so if one has ended up in your React Native app, treat it as compromised: rotate or delete the service account key in the Google Cloud console immediately, remove it from the app, and move any privileged server operations to an actual backend. Confusing the safe config key with a real secret, in either direction, is the error to avoid, and knowing which is which is the whole answer.
Safe versus unsafe Firebase credentials
Sorting your Firebase credentials makes clear what may ship. The table below compares them.
| Credential | Ship it in the app? | What controls access |
|---|---|---|
| Firebase Web config, including apiKey | Yes, safe by design | Security Rules, Authentication, App Check |
| Service account or Admin SDK key | Never | It bypasses rules; server-side only |
| Custom third-party API secret | Never | Keep behind a backend proxy |
| Your Firestore or database data | Reached with the config | Security Rules plus Authentication |
Read the table by whether a credential grants privilege on its own: the config does not and is safe, while the service account key does and must never ship.
Firebase security checklist
Working through these steps secures a React Native Firebase app correctly. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Include the config | The Web config in the app is fine | [ ] |
| Never ship the service account | Keep the Admin SDK key server-side | [ ] |
| Write strict Security Rules | Deny by default, scope to the signed-in user | [ ] |
| Leave test mode | No allow-all rules in production | [ ] |
| Enable App Check | Attest that requests come from your app | [ ] |
| Restrict the API key | Limit its allowed apps and APIs | [ ] |
The step that carries the most weight is writing strict Security Rules, because they, not the visibility of your config, are what actually decide who can access your data.
Audit your React Native build
Because the real risk is a genuine secret slipping into the app rather than the config being visible, checking what actually ships is worthwhile, especially when an AI code generator or a copied snippet may have added an Admin SDK key. Knowing whether a true secret is present, and how your data is handled, is the input to a correct Firebase setup.
A scanner like PTKD.com analyzes your React Native build and reports issues such as leaked keys and secrets, insecure data storage, and over-broad permissions by severity, mapped to OWASP MASVS, so a service account key that wrongly ended up in the app is flagged, unlike the harmless config. To be clear about the boundary: PTKD does not write your Security Rules or configure App Check. It finds a real secret in the build so you know what to rotate and remove, while your rules do the data protection.
What to take away
- It is safe to put the Firebase config, including the apiKey, in a React Native app, because the config identifies your project rather than authorizing access.
- The Web API key in your config is a public identifier, while a service account or Admin SDK key is a real secret that must never ship in the app.
- Firebase Security Rules, with Authentication, are what actually protect your data, so weak or test-mode rules, not a visible config, are the real exposure.
- Add App Check and API key restrictions as defense in depth, but rely on Security Rules as the core protection.
- Audit your build with a tool like PTKD.com to catch a service account key that slipped into the app, and fix data exposure in your rules.
