Backend for frontend patterns reduce secret exposure in public clients

At a glance

What this is: This analysis argues that public clients cannot safely store API keys and that a backend for frontend is the practical control boundary for sensitive third-party access.

Why it matters: For IAM and NHI teams, the issue is whether secrets, sessions, and privilege controls stay server-side enough to support rotation, auditability, and least privilege.

👉 Read GitGuardian's analysis of backend for frontend secret protection

Context

Frontend code runs in an environment the operator does not control, which means any embedded secret should be treated as exposed rather than hidden. That creates a direct NHI governance problem when API keys, tokens, or certificates are placed in browser bundles, mobile apps, or desktop clients.

The article frames the Backend for Frontend pattern as a way to move secrets and privileged calls to a server-side layer so the public client only handles session-based requests. That is a familiar architecture choice, but the governance question is broader than application design: it determines whether a secret is a manageable NHI or an artifact distributed to users.

For IAM teams, the operational tension is not whether frontends need third-party APIs. It is whether the access boundary can be enforced where identity, logging, rotation, and revocation are actually controllable. In that sense, the problem is typical across modern application teams, even if the implementation details vary by platform.

Key questions

Q: How should security teams handle secrets in frontend applications?

A: Security teams should assume that any secret embedded in a frontend application is exposed to users and attackers. The practical fix is to move privileged API calls to a server-side BFF, keep credentials in a secrets manager, and use short-lived session mechanisms that do not place secrets in shipped client code.

Q: When does a backend for frontend make more sense than direct client-to-API access?

A: A backend for frontend makes more sense when the API key has financial, administrative, or data-access consequences, or when the client is a public client such as a browser, mobile app, or desktop app. In those cases, the BFF creates a controlled custody point for secrets and authorization.

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.

Q: Should production secrets live in environment variables or a secrets manager?

A: Production secrets should live in a secrets manager, not as the only storage mechanism in environment variables. A secrets manager gives you runtime retrieval, centralized access control, rotation, and audit trails, which are essential when a leaked secret must be replaced quickly without redeploying code.

Technical breakdown

Why public clients cannot safely store secrets

A public client is software whose runtime or build artifact is delivered to the user, such as a browser app, mobile app, or desktop package. Once the code is distributed, secrets embedded in it are no longer secrets because the user can inspect memory, bundles, network traffic, or decompiled resources. Environment variables in frontend frameworks do not change that model if they are compiled into the shipped artifact. From an identity perspective, the embedded key becomes a non-human identity with no trustworthy custody boundary, which means the problem is architectural rather than cosmetic.

Practical implication: Treat any secret in client-distributed code as compromised and move it behind a server-side trust boundary.

How a backend for frontend changes the secret custody model

A backend for frontend, or BFF, sits between the client and downstream APIs and performs authenticated calls on behalf of the client. The frontend sends a user session to the BFF, the BFF checks authorization, and the BFF attaches secrets that never reach the client. This is not just proxying. It creates a place where access can be scoped, logged, rotated, and revoked without changing the shipped frontend artifact. For NHI governance, the BFF becomes the system of custody for API credentials, while the frontend becomes a public requester rather than a credential holder.

Practical implication: Place sensitive API access behind the BFF and treat the BFF as the governed owner of those NHI credentials.

Why secrets managers matter more than environment variables in production

Environment variables can work as a convenience layer, but they do not provide durable lifecycle controls for production secrets. A secrets manager enables rotation without redeploying, centralizes access control, and creates an audit trail for retrieval events. That matters because leaked or overused credentials are operational incidents, not just configuration defects. In a mature setup, the BFF retrieves secrets at runtime and the deployment pipeline injects only what the runtime needs. That separation reduces blast radius and gives IAM and security teams a real revocation path when a key is exposed.

Practical implication: Use a secrets manager for production credentials and design for rotation, auditing, and least-privilege retrieval.

Threat narrative

Attacker objective: The attacker wants durable access through a credential that outlives the original application session and can be reused outside the frontend.

1. Entry occurs when a secret is embedded in browser code, a mobile bundle, or a desktop client and can be extracted with basic inspection tools.
2. Escalation follows when the extracted key is reused to call third-party APIs directly, bypassing intended user-session controls and rate governance.
3. Impact is unauthorized data access, charge abuse, or administrative actions performed with the stolen NHI credential.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public clients create ephemeral credential trust debt: if a secret ships to the user, the organisation inherits an access control problem that cannot be fully repaired in the browser. The debt grows when teams rely on obfuscation, build-time variables, or client-side storage to hide credentials. The practical conclusion is simple: sensitive NHI controls belong on infrastructure the operator controls, not in distributed code.

The BFF pattern is a governance boundary, not just a design pattern. Its security value comes from relocating privileged API calls into a server-side context where identity, logging, and rotation are enforceable. That matters because the frontend becomes a public interface while the BFF owns the non-human credential. Practitioners should evaluate the BFF as part of IAM architecture, not as a frontend convenience.

Secrets managers turn one-time leaks into manageable events. Production NHI controls depend on the ability to rotate, audit, and scope access without rebuilding the application. Environment variables do not deliver that lifecycle reliably at scale. Teams that treat secret storage as deployment plumbing will struggle to respond within the minutes that modern leak detection and abuse patterns demand.

Mobile and desktop applications make the NHI problem harder, not different. The distribution model changes, but the security logic does not: any embedded credential is available to the end user. That means certificate pinning, secure storage, and short-lived tokens help at the edge, yet they do not replace the need to move privileged access into a governed backend. The practitioner takeaway is to design for custody first and distribution second.

The market signal is clear: application teams need identity-aware proxy patterns, not more hidden keys. As third-party API dependence grows, the control plane for NHI credentials must support session validation, rate limiting, and least privilege together. Teams that still treat embedded keys as acceptable engineering shortcuts are carrying governance risk that will eventually surface as incident response work.

From our research:

• 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned," according to The 2024 State of Secrets Management Survey.
• Only 44% of organisations are currently using a dedicated secrets management system, which leaves rotation and audit controls fragmented across teams and tools.
• For a broader control baseline, review Guide to the Secret Sprawl Challenge for the operational patterns that turn exposed secrets into recurring NHI risk.

What this signals

Ephemeral credential trust debt is the hidden cost of shipping secrets to public clients: once a key leaves the server, the organisation inherits a lifecycle problem that app code cannot solve on its own. That is why secret custody, rotation, and revocation should be designed into the identity architecture rather than patched into release workflows. For teams aligning to broader guidance, the NIST Cybersecurity Framework 2.0 still provides the governance vocabulary, but the implementation needs NHI-specific controls.

With 88% of security professionals concerned about secrets sprawl, per The 2024 State of Secrets Management Survey, the programme-level issue is no longer awareness. The next decision is whether application teams can prove that exposed credentials are rotated quickly, access is scoped narrowly, and runtime retrieval is observable.

Practitioners should expect more pressure to separate frontend delivery from secret custody as AI-enabled and API-heavy applications multiply. The control model is converging on server-side custody, runtime retrieval, and audited access, which aligns closely with OWASP Non-Human Identity Top 10 thinking for secret sprawl, privilege scope, and recovery.

For practitioners

• Move sensitive API access behind a BFF Route requests through a server-side layer so the frontend never handles secrets that can be extracted from distributed code. Use the BFF to validate the user session before forwarding any privileged request.
• Store production secrets in a manager Use AWS Secrets Manager, HashiCorp Vault, or an equivalent runtime secrets service so credentials can be rotated and audited without redeploying the application.
• Separate session cookies from client storage Prefer HttpOnly, Secure, SameSite cookies for browser sessions and keep tokens out of localStorage, where XSS can steal them.
• Apply least privilege to BFF credentials Grant the BFF access only to the specific secrets and APIs it needs, and split payment, content, and analytics credentials so one compromise does not expose everything.
• Test for extractable secrets in shipped artifacts Inspect frontend bundles, mobile packages, and desktop builds for credentials before release and after every major build pipeline change.

Key takeaways

• Secrets in frontend code are not hidden in any meaningful security sense because the user controls the runtime and the artifact.
• A BFF gives security teams a place to enforce session checks, credential custody, rotation, and auditability before third-party APIs are reached.
• Production secrets need a lifecycle control plane, which is why secrets managers outperform environment variables for anything with real access or financial impact.

Key terms

• 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.
• 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.
• Secrets Manager: A secrets manager is a dedicated service for storing, retrieving, and rotating credentials such as API keys, tokens, and certificates. It provides centralized control, auditability, and runtime access patterns that support production NHI governance far better than embedding secrets in code or configuration files.
• HttpOnly Cookie: An HttpOnly cookie is a session cookie that JavaScript cannot read, which reduces the risk of theft through client-side script compromise. In BFF architectures, it is a common way to keep authentication material out of browser-accessible storage while still allowing the server to authorize requests.

What's in the full article

GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:

• Concrete deployment patterns for integrated BFFs in Next.js, Nuxt, Remix, and SvelteKit
• Serverless runtime examples for AWS API Gateway, Lambda, Cloud Run, and Cloud Functions
• Implementation detail for HttpOnly cookies, secure session handling, and certificate pinning on mobile clients
• Rotation and CI/CD injection patterns that keep secrets out of build artifacts and source control

👉 The full GitGuardian post covers deployment patterns, mobile session handling, and production rotation detail.

Deepen your knowledge

Frontend secret exposure and server-side custody are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to move privileged access out of public clients, this is a relevant starting point.