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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on GitGuardian's blog post: Public clients cannot safely store secrets, and a backend for frontend pattern shifts credential handling to a server-side boundary.
Why it matters: It matters because teams responsible for NHI, IAM, and application security need a clean boundary for API keys, rotation, and auditability before secrets leak into user-controlled code.
👉 Read GitGuardian's analysis of backend for frontend patterns and secret leakage in public clients
Context
Public clients are applications that run in an environment the operator does not control, such as browsers, mobile devices, and desktop installs. In those environments, any embedded secret can be extracted from code, bundles, or runtime traffic, which turns secret storage into a governance problem rather than a coding shortcut.
The article’s core identity issue is NHI handling at the edge of the application. If an API key, token, or other secret grants financial or administrative access, it should not live in a public client at all. A backend for frontend creates a controlled server-side boundary so the secret stays in infrastructure the organisation can govern.
The article also distinguishes between development convenience and production control. Environment variables may help during local development, but the operational requirement is rotation, access control, and audit trails that only a server-side secrets manager can support.
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. That breaks the basic confidentiality assumption behind secret storage and turns rotation, revocation, and auditability into guesswork. The safe design is to keep the credential on a server-side component the user cannot inspect.
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. A backend for frontend keeps the key on controlled infrastructure and uses the user session to decide whether a request should be forwarded. That preserves both confidentiality and accountability.
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. A good test is whether exposing that credential would create financial, administrative, or data-access impact. If yes, production handling should be server-side and centrally managed.
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.
Technical breakdown
Why public clients cannot hold secrets
A public client is code delivered to a user-controlled device, so its runtime and build artefacts are inspectable. That means secrets embedded in JavaScript bundles, mobile packages, or desktop binaries are recoverable with basic tooling, even if they are obfuscated or injected through build-time variables. This is not primarily a vulnerability in one framework. It is a property of the client type. In OAuth terms, a confidential client can keep secrets because the operator controls the execution environment. A public client cannot make that guarantee, so the secret boundary has to move elsewhere.
Practical implication: Treat any credential used directly by a public client as exposed and redesign the flow so the client never receives it.
How a backend for frontend changes the secret boundary
A backend for frontend, or BFF, inserts a server-side layer between the frontend and external APIs. The frontend authenticates to the BFF with a session mechanism, and the BFF attaches the protected secret when it calls third-party services. That keeps the secret off the client device and lets the server enforce session validation, request filtering, and least privilege before any downstream API call happens. The BFF is not just a proxy. It becomes the point where identity, authorisation, and secret use are governed together.
Practical implication: Place the credential boundary in the BFF so access decisions and secret use are enforced before requests leave your environment.
Why secrets managers matter more than environment variables
Environment variables are convenient configuration, but they are weak production secret storage because they do not solve lifecycle governance. A dedicated secrets manager supports rotation, centralised access control, and audit trails, which are essential once a secret has financial impact, admin scope, or incident-response sensitivity. The article’s practical point is that rotation must happen without redeployment. That is the difference between a secret that can be operationally governed and one that is merely hidden during build or launch.
Practical implication: Use a secrets manager for production credentials so rotation and auditing remain possible after deployment.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group 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.
Backend for frontend is a governance boundary, not just an integration pattern: The architectural value is that the BFF becomes the point where session validation, secret use, and downstream authorisation intersect. That matters because it reassigns control from an inspectable public client to a server-side identity domain that can actually enforce policy. Practitioners should treat the BFF as the place where access to third-party APIs becomes governable.
Secrets manager use is the operational proof of proper NHI lifecycle control: If credentials cannot be rotated, audited, and centrally revoked, they are not being governed, only stored. Hardcoded or build-embedded secrets create persistent exposure windows, while managed secrets let teams change credentials without redeploying every consumer. The practical conclusion is that production secret handling must be lifecycle-driven, not deployment-driven.
Access that can be inspected by the user is not a protected privilege: The article sharpens a useful concept for identity programmes, which is public-client secret exposure. A credential that ships into a user-controlled runtime has already crossed the governance line, even if it has not yet been abused. Practitioners should use that concept to separate harmless configuration from credentials that require server-side custody.
Frontend teams now own a hidden identity problem: The moment a frontend calls a financial or administrative API directly, it inherits NHI governance responsibilities it is poorly suited to manage. That makes API-key placement, runtime secret retrieval, and off-client enforcement part of application architecture rather than a late-stage security review. Teams should re-evaluate which front-end integrations are actually server-side identity flows in disguise.
From our research library:
- 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.
- Read next: Secrets Management Guide
What this signals
Secret exposure moves fastest where the client runs in user-controlled code: Browser bundles, mobile packages, and desktop executables all collapse the assumption that the operator can protect the runtime. That means teams need to treat client-side credential placement as a governance decision, not a developer convenience.
Public-client secret exposure: this is the pattern practitioners should name when a credential is embedded in code that ships to a user device. Once that label is in place, the right control question becomes where the secret is issued, stored, and rotated, not how well it is hidden in the bundle.
A BFF only solves the problem if the server-side boundary is paired with lifecycle control for the underlying credentials. If rotation, auditability, and revocation remain manual, the architecture improves secrecy but not governance.
For practitioners
- 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.
- Harden the BFF as a privileged control point Apply session validation, least privilege, request throttling, and input validation to the BFF because it now sits on the credential path to third-party services.
- Separate development convenience from production governance Allow environment variables only for non-production use, and treat any production secret embedded in build artefacts, logs, or client bundles as a removal priority.
Key takeaways
- Public clients are the wrong place for secrets because the user can inspect the code, runtime, and bundled artifacts.
- A backend for frontend moves credential use to a server-side boundary, which makes session control and secret handling governable together.
- Production secret storage needs rotation and audit trails, so a dedicated secrets manager is the practical companion to any BFF design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is fundamentally about secrets exposed in public clients and build artefacts. |
| NHI-07 — Long-Lived Secrets | Rotation and revocation are central because production secrets must be changed without redeploying. | |
| NHI-10 — Human Use of NHI | The pattern warns against exposing machine credentials directly in user-facing application code. | |
| Recommendation — Remove secrets from public clients and keep them only in governed server-side storage. Eliminate long-lived credentials that cannot be rotated or revoked centrally. Prevent humans from embedding operational credentials into user-facing clients. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Production credentials need lifecycle management, rotation, and revocation controls. |
| Recommendation — Apply authenticator management to rotate and revoke application credentials centrally. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The BFF boundary exists to control which services can use which credentials. |
| Recommendation — Constrain credential access to the BFF and the specific services it must call. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article addresses how exposed client-side secrets are easy targets for credential access. |
| Recommendation — Hunt for client-side credential exposure patterns that enable credential access. | ||
Key terms
- Public Client: A public client is an application that runs in an environment the operator does not fully control, such as a browser, phone, or desktop device. Because users can inspect its code and runtime, it cannot safely hold secrets that require custody, confidentiality, or reliable rotation.
- Backend For Frontend: A backend for frontend is a server-side layer built specifically for one client application, such as a web app or mobile app. It aggregates data, enforces session checks, and keeps privileged API credentials away from distributed client code, which makes it a control boundary as well as an architecture pattern.
- Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
- Confidential Client: An application that runs on infrastructure the operator controls and can therefore keep secrets securely. Unlike a public client, it can protect credentials because users do not have direct access to its filesystem, memory, or deployment environment.
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
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org