TL;DR: GitGuardian argues that browser bundles, mobile apps, and desktop clients cannot safely hold API keys because embedded secrets are extractable, and that a backend for frontend should keep credentials server-side while production deployments rely on a secrets manager for rotation and auditing. The core governance shift is that secret handling must move out of public clients and into controlled runtime access.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “Stop Leaking API Keys: The Backend for Frontend (BFF) Pattern Explained”.
Key questions
Q: What breaks when a public client is used to store API keys?
A: A public client gives users access to the code and runtime artifacts, so any embedded API key can be extracted sooner or later.
Q: Why do financial or admin API keys belong behind a backend for frontend?
A: Keys that can move money, modify data, or access sensitive services should not be exposed to client devices because the client cannot enforce secrecy.
Q: How do teams know a secret should move from a frontend into a secrets manager?
A: If a credential needs rotation, revocation, or audit trails, it belongs in a secrets manager rather than in code or environment variables embedded in a client build.
Practitioner guidance
- Define public-client secret boundaries Inventory every browser, mobile, and desktop client that currently receives an API key, token, or other credential, then remove direct secret use from those runtimes.
- Move sensitive API calls behind a BFF Route calls that need financial or administrative credentials through a server-side BFF so the frontend only sends the user session and never sees the downstream secret.
- Use a production secrets manager for runtime retrieval Store live credentials in a secrets manager and fetch them at runtime so you can rotate keys, audit access, and revoke secrets without redeploying code.
Bottom line: Public clients are the wrong place for secrets because the user can inspect the code, runtime, and bundled artifacts.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step BFF deployment patterns for integrated frameworks, standalone services, and serverless runtimes
- Implementation detail for cookie-based sessions, certificate pinning, and mobile-specific secure storage
- Examples of runtime secret injection for ECS, Kubernetes, and cloud functions without baking credentials into images
- Guidance on when a secrets manager should replace environment variables in production
👉 Read GitGuardian's analysis of backend for frontend patterns and secret leakage in public clients →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Public clients are structurally incapable of being trusted as secret holders: The assumption that a frontend can safely conceal a credential was always designed for a controlled runtime, not for code shipped to users. That assumption fails in browsers, mobile apps, and desktop bundles because the operator does not control the execution environment or the artefacts. The implication is that credential governance must begin with client classification, not with better obfuscation.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between a BFF and an API gateway?
A: An API gateway handles shared infrastructure concerns such as authentication, rate limiting, and traffic entry for many clients. A BFF is specific to one frontend and focuses on session handling, data shaping, and privileged API calls for that client, which makes it the better place to isolate secrets.
👉 Read our full editorial: Backend for frontend patterns reduce secret exposure in public clients