Firebase Remote Config is a convenient way to change your app's behavior without shipping an update, and that convenience invites two security mistakes: treating it as a place to store secrets, and trusting its values to make security decisions on the client. Remote Config values are delivered to the device and can be read, so they are not secret, and a client that fetches them can be manipulated, so they cannot be the authority for anything that matters. There is also an App Store angle around changing behavior after review. Here is how to use Remote Config without those traps.
Short answer
Firebase Remote Config lets you change your app's behavior and appearance without an app update by fetching configuration values from Firebase. Per Firebase's documentation, the security points are that you must not store secrets in Remote Config, because the values are delivered to the client and can be read, and you must not rely on it to enforce security-critical decisions on the client, since a client can be manipulated. Use it for non-sensitive configuration and feature flags within your app's reviewed functionality, enforce real decisions like entitlements server-side, and set safe defaults. Treat Remote Config values as public, client-side inputs, not as a secret store or a security boundary.
What you should know
- Remote Config values are not secret: they are delivered to and readable on the client.
- Do not store secrets in it: keys and credentials do not belong there.
- Do not enforce security on the client: a client can be manipulated.
- Use safe defaults: the app should behave safely if a fetch fails.
- Keep changes within reviewed functionality: avoid hiding features from review.
What is Firebase Remote Config?
It is a service for changing your app's behavior and appearance without releasing a new build. You define parameter values in the Firebase console, your app fetches them, and your code uses them to adjust things like UI, feature flags, or tuning values, with in-app defaults used until a fetch succeeds. This is genuinely useful for rolling out changes gradually, running experiments, or adjusting configuration without an update. The security implications come from how it works: the values travel to the device and are applied by client code, so they are visible to anyone inspecting the app or its traffic, and the client deciding based on them is, like any client, something an attacker can tamper with. So Remote Config is a configuration delivery mechanism, not a secure channel or a trusted authority, and using it as either is the mistake.
What should you not put in Remote Config?
Anything secret or security-critical. The table clarifies.
| Use | Appropriate? |
|---|---|
| API keys, credentials, or secrets | No; values are readable on the client |
| Non-sensitive feature flags and UI config | Yes; within your reviewed functionality |
| Client-side entitlement or paywall enforcement | No; enforce entitlements server-side |
| Tuning values and gradual rollouts | Yes; with safe defaults |
| Hidden features revealed after review | No; that violates Guideline 2.3.1 |
The two things to keep out are secrets, since the values are delivered to the client and can be read, and security decisions, since a manipulated client can ignore or change a config value. A feature flag that, for example, decides whether a paywall applies must be backed by server-side enforcement, because a tampered client could simply flip it. Remote Config can toggle the UI, but the entitlement check has to live on your server.
How do you use it securely?
For non-sensitive configuration, with server-side enforcement and safe defaults. Use Remote Config for things that are fine to be public and client-side: UI variations, non-sensitive feature flags, rollout percentages, and tuning. Never put secrets in it, and never let a Remote Config value be the sole gate on something security-critical like access to paid features or sensitive data, enforce those on your backend, where the client cannot override them, and use the config only to reflect the result in the UI. Set safe default values so that if a fetch fails or is blocked, the app behaves correctly and securely rather than defaulting to an open state. And keep changes within the functionality your app was reviewed for, since using Remote Config to reveal undisclosed features after approval is the hidden-feature behavior Guideline 2.3.1 prohibits. Used this way, Remote Config is a useful configuration tool that does not become a security or compliance liability.
What to watch out for
The first trap is storing a secret in Remote Config, which is readable on the client; keep secrets out. The second is gating entitlements or sensitive access on a Remote Config value the client could tamper with; enforce those server-side. The third is using Remote Config to flip the app into undisclosed behavior after review, which violates Guideline 2.3.1. A pre-submission scan such as PTKD.com (https://ptkd.com) reads your app against OWASP MASVS and surfaces hardcoded secrets and how the app handles data, which complements keeping secrets out of Remote Config and enforcing decisions server-side. The configuration design is yours to set in Firebase and your backend.
What to take away
- Firebase Remote Config changes app behavior without an update, but its values are delivered to the client and are not secret.
- Do not store secrets in it, and do not let it be the authority for security-critical decisions, since a client can be manipulated.
- Use it for non-sensitive configuration and feature flags within reviewed functionality, enforce entitlements server-side, and set safe defaults.
- Avoid using it to reveal hidden features after review (Guideline 2.3.1), and use a pre-submission scan such as PTKD.com to confirm no secrets are exposed.
