Subdomain takeover can leak API keys from localStorage

At a glance

What this is: This is an analysis of how dangling CNAME records and client-side secret storage can combine to let attackers steal API keys from a taken-over subdomain.

Why it matters: IAM and application teams need to treat custom-domain verification and browser-stored secrets as linked controls, because a DNS ownership gap can become a credential theft path.

👉 Read Truffle Security's analysis of subdomain takeover and localStorage secret theft

Context

Subdomain takeover becomes materially more dangerous when a web application also stores sensitive data in browser storage. In this case, the security gap is not just control of the hostname, but control of a trusted execution context that can read localStorage and cookies.

That creates an identity and secrets governance problem, not only a web-hosting problem. If an attacker can inherit a customer-facing subdomain, they may also inherit a path to secrets that users believed were private to their session.

Key questions

Q: How should security teams prevent subdomain takeover from creating a larger identity compromise path?

A: Security teams should maintain continuous external attack surface monitoring, verify ownership of every delegated subdomain, and remove or remediate dangling DNS records quickly. A takeover becomes dangerous when a trusted domain can be repurposed to host attacker-controlled content or capture tokens. The practical goal is to shorten exposure windows and treat subdomains as governed assets, not static records.

Q: Why does localStorage create so much risk for API keys and tokens?

A: localStorage is readable by any script that runs in the same browser origin, so a hostile page or takeover can retrieve anything stored there. If the application also keeps the decryption material in the client context, encryption offers little real protection. Sensitive credentials should be kept off the browser whenever possible, or replaced with ephemeral, narrowly scoped tokens.

Q: What are the signs that a custom-domain workflow is unsafe?

A: Common warning signs include dangling CNAME records, abandoned tenants that can still be re-bound, and domain onboarding that does not require fresh proof of ownership. Another red flag is any workflow where a former customer’s hostname can be reassigned without administrative review. Those conditions make takeover and impersonation much easier for attackers.

Q: What should teams do when a SaaS portal stores credentials in the browser?

A: Assume that any browser-stored credential can be recovered by code execution on that origin, then redesign the workflow so the browser never sees a reusable secret. Replace long-lived values with session-bound access, tighten retention, and verify that logout, tenant deletion, and domain removal actually clear the stored material. That is the only reliable way to reduce the exposure window.

Technical breakdown

How dangling CNAME records create subdomain takeover risk

A dangling CNAME appears when a domain still points at a SaaS target after the original customer has removed or abandoned the service. If the platform allows another account to claim that hostname, the attacker can serve content on a trusted subdomain. The danger increases when the application permits custom HTML, JavaScript, or other active content, because the attacker then controls code execution in the victim-origin context. That makes the takeover more than a branding or availability issue. It becomes a platform trust failure in which ownership validation and domain lifecycle controls are too weak to prevent hostile reuse. See the Attack Surface Management Guide.

Practical implication: Require strong domain ownership validation before binding a custom domain.

Why localStorage turns a subdomain takeover into credential theft

localStorage is origin-scoped browser storage, which means any script running on the compromised subdomain can read values saved there for that origin. In the article’s example, the documentation portal also stored API credentials in localStorage and relied on a cookie-based decryption key. That design creates a dangerous compound condition: the attacker does not need server compromise if they can control client-side execution on the trusted origin. Once the malicious script runs, it can retrieve the stored secret, decrypt it if needed, and exfiltrate it to an external collector. The issue is not encryption alone, but the decision to keep usable secrets in a browser-accessible store. See the Secrets Management Guide.

Practical implication: Move sensitive credentials out of browser storage and treat localStorage as hostile for secrets.

Why custom-domain onboarding needs both DNS and account binding controls

A secure custom-domain workflow should verify two things: that the requester controls the DNS record and that the domain cannot later be reassigned without explicit ownership proof. The article describes a failure mode where a deleted customer account leaves a dangling CNAME behind, then another account can bind that hostname and inherit the trust boundary. A stronger design uses challenge-based verification, such as a unique TXT record, or permanent account binding for first registration. That is a governance control over identity of the domain, not just a routing control. Without it, the platform cannot distinguish an abandoned namespace from a legitimately transferred one.

Practical implication: Add lifecycle checks for domain ownership before and after custom-domain registration.

Threat narrative

Attacker objective: Steal reusable API keys from users who trust the compromised subdomain.

1. An attacker first finds or creates a dangling custom domain that still points to the SaaS provider, then claims it through the platform’s weak ownership checks.
2. The attacker injects JavaScript into the taken-over subdomain and waits for a victim to visit the trusted origin, where the script can access browser-stored secrets.
3. The malicious code reads the decrypted credential material from localStorage and exfiltrates the API key to an attacker-controlled server.
4. The end result is theft of a live API secret from a legitimate user session, not just control of the subdomain itself.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Subdomain takeover is now an identity problem when the origin stores secrets. The control failure is not just stale DNS, but the assumption that a trusted hostname remains trustworthy after customer churn or account deletion. Once a subdomain can be reassigned, browser storage, cookies, and any origin-bound secrets become exposed to a new party. That shifts the risk from infrastructure hygiene to identity and secrets governance, because the platform has lost control of who can speak for the origin.

LocalStorage is an unsafe persistence layer for any credential that can unlock other systems. Encryption inside the browser does not meaningfully help if the decryption material is also present in the same execution context. The article shows the weakness of treating client-side secrecy as equivalent to server-side protection. For IAM and NHI practitioners, the lesson is that reusable API keys should be managed like privileged secrets, not like convenience data for a developer experience portal.

Domain ownership verification must be treated as a lifecycle control, not a one-time onboarding step. If a platform allows abandoned domains to be re-claimed without fresh proof of control, it creates an offboarding gap that attackers can exploit later. That is especially relevant where the domain front-ends API tooling, because the subdomain becomes part of the credential handling path. The governance lesson is simple: lifecycle ownership must follow the DNS record as closely as it follows the account.

Secret exposure through trusted SaaS interfaces is a supply-chain style failure, even when no backend is breached. The attacker is abusing the platform’s delegated trust boundary, not breaking into the provider’s core systems. That matters because many organisations assume vendor-hosted documentation or sandbox tools are low-risk contexts for secrets. In practice, any place that stores API keys in the browser expands the blast radius of a domain takeover. Treat those interfaces as credential surfaces, not just support utilities.

OWASP-NHI-02 Secret Leakage and OWASP-NHI-03 Vulnerable Third-Party NHI fit this pattern tightly. The article illustrates both exposed secret handling and reliance on a third-party-hosted workflow that can be subverted through domain reassignment. The important point is that the risk chain begins with governance failures around ownership and ends with secret extraction from a non-human credential path. That is exactly the kind of cross-boundary failure NHI programmes need to inventory and remove.

What this signals

Secret persistence in the browser is a governance failure, not a convenience feature. Teams that let reusable API keys live in localStorage create a hidden recovery path for attackers who can execute JavaScript on the same origin. The better pattern is to issue short-lived credentials and keep the long-lived trust anchor outside the browser entirely.

Domain lifecycle controls now belong in the same review cycle as secrets management. A custom domain is not just a routing record; it is part of the application’s trust boundary. If your programme does not re-check ownership when tenants are deleted, renamed, or migrated, you have an identity handoff problem that can outlive the original account.

Browser-accessible secrets deserve the same scrutiny as exposed API surfaces. A portal that stores credentials client-side effectively expands the attack surface to every origin compromise, takeover, or malicious script execution path. That makes secret residency, not just secret rotation, a core control objective.

For practitioners

• Harden custom-domain verification Require a unique DNS proof of control, such as a TXT challenge, before associating any customer domain with a tenant.
• Eliminate secrets from browser storage Review whether API keys, tokens, or passwords are stored in localStorage, and move any credential material to server-side or ephemeral handling.
• Inventory dangling CNAME records Audit customer-facing domains for stale records that still point to deprovisioned SaaS endpoints, then revoke or rebind them before reuse.
• Treat documentation portals as credential surfaces Apply the same review discipline to developer portals and API sandboxes that you would apply to other secrets workflows, including retention and session handling.

Key takeaways

• The article shows how a subdomain takeover can become a secret-exposure event when the application also stores API keys in browser-accessible storage.
• The impact is shaped by both dangling DNS ownership and client-side secret handling, so fixing only one side leaves residual risk.
• Practitioners should verify custom-domain ownership, remove sensitive data from localStorage, and audit abandoned hostnames that still point at SaaS endpoints.

Related NHI Mgmt Group resources: API Key Management Guide · Secrets Management Guide · Attack Surface Management Guide · Guide to the Secret Sprawl Challenge

Key terms

• Subdomain Takeover: An attack in which someone claims or recreates a service behind a dangling subdomain and uses the trusted name to serve malicious content. The key issue is not the parent domain compromise, but the attacker inheriting trust through a stale pointer.
• LocalStorage: LocalStorage is browser-side storage tied to an origin, used to persist small amounts of data across sessions. In desktop applications that rely on embedded web content, it can retain sensitive state such as connection details or tokens. If the origin boundary is weak, stored data may help an attacker regain trust or pivot.
• Dangling CNAME: A dangling CNAME is a DNS alias that still points to a service or platform that no longer exists or is no longer owned. It creates an opportunity for subdomain takeover because the name remains active even though the target has been abandoned.
• Browser-Resident Secret: A browser-resident secret is any credential, token, or key stored in client-side storage, cookies, or page state where JavaScript can access it. These secrets often persist longer than intended and can be stolen through script injection, takeover, or malicious extensions, so they should be treated as high-risk exposure points.

What's in the full article

Truffle Security's full post covers the operational detail this post intentionally leaves for the source:

• The exact attack chain used to combine a dangling CNAME with browser-side script execution
• The JavaScript exploit logic used to recover secrets from localStorage and cookies
• The disclosure timeline, including how the vendor and impacted customers were notified
• The recommended remediation steps for SaaS providers that support custom domains

👉 The full Truffle Security post covers the attack chain, disclosure process, and remediation advice for custom-domain workflows.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.