What should organisations do when an application stores credentials in browser storage and supports custom domains?

Why This Matters for Security Teams

browser storage turns a convenience feature into a credential exposure problem when applications accept custom domains. If the app saves tokens, API keys, or session material in localStorage, any verified subdomain that becomes exposed can be used as a path to exfiltrate secrets. That matters because the attack surface is not just the app itself, but the domain mapping, account binding, and client-side trust model that surround it. Current guidance suggests treating browser storage as hostile by default and reducing what is ever persisted there.

This is especially important in environments where custom domains are delegated to customers, partners, or internal business units. Domain verification alone does not guarantee safety if account ownership can be reassigned, mappings can drift, or first-use binding is weak. NHI governance also applies here because browser-held credentials are still secrets, and secret sprawl is often the first failure mode. NHIMG has repeatedly highlighted how exposed secrets become breach accelerants in real incidents, including the Guide to the Secret Sprawl Challenge and the Google Firebase misconfiguration breach.

In practice, many security teams discover the problem only after a tenant-controlled domain has already been used to surface data or credentials, rather than through intentional review of browser storage and domain-binding assumptions.

How It Works in Practice

The safest pattern is to separate domain trust from credential trust. A verified custom domain should prove control of DNS or an equivalent ownership signal, but that proof should not automatically grant broad access to browser-stored secrets. Instead, bind the verified domain to a specific account, tenant, or workspace at first approval, then require re-verification for any domain change, transfer, or privileged role change. That reduces the chance that a later takeover, repointing, or support-side reassignment silently inherits prior trust.

Client-side secret reduction is the second control. Store the minimum possible state in browser storage, and prefer short-lived session artefacts over reusable secrets. Where an application must persist something client-side, the better question is whether it is a secret at all. Many teams can move to server-side session handling, token exchange, or one-time bootstrap flows so the browser never sees long-lived credentials. That aligns with the broader NHI principle that secrets should be dynamic and tightly scoped, not durable. NIST’s NIST SP 800-63 Digital Identity Guidelines are useful for thinking about identity assurance, while the OWASP Non-Human Identity Top 10 helps teams frame secret handling as an identity and lifecycle issue, not just a frontend concern.

• Verify domain ownership before any secret-bearing feature is enabled.
• Lock the first verified domain to the first verified account or tenant.
• Re-check mappings after transfer, suspension, or support intervention.
• Minimise localStorage use; prefer ephemeral session state where possible.
• Inventory every browser-stored credential, token, and API key.

These controls tend to break down in multi-tenant SaaS platforms with delegated admin rights and weak support workflows, because domain control can change faster than security teams can revalidate account binding.

Common Variations and Edge Cases

Tighter browser-secret controls often increase support overhead, requiring organisations to balance user convenience against the risk of domain abuse and token leakage. There is no universal standard for this yet, so best practice is evolving rather than settled.

Some products cannot eliminate client-side storage entirely because they must support offline behaviour, embedded widgets, or cross-origin integrations. In those cases, reduce persistence aggressively, use short TTLs, and avoid placing high-value secrets in any storage that can be read by script. Also be careful with custom domains that are expected to be user-managed: what looks like a benign branding feature can become an exfiltration surface if a previously trusted subdomain is repointed or reused.

NHIMG’s reporting on the Ultimate Guide to NHIs — Static vs Dynamic Secrets is directly relevant here, because browser-stored credentials behave like static secrets even when the application presents them as temporary. When organisations fail to distinguish those cases, they end up with long-lived exposure hidden inside a frontend feature. That is exactly the kind of issue seen in breach write-ups such as the IOS app secrets leakage report.

Related resources from NHI Mgmt Group

• Why does relying on trusted browser extensions create security risk for organisations?
• What are the risks of using static credentials in MCP servers?
• What is the impact of using hard-coded credentials on security?
• How should teams reduce the risk of exposed AI credentials being abused?