Manifest V3 lowers risk by limiting persistent background execution, tightening permissions, and disallowing remotely hosted code. Those controls reduce opportunities for unreviewed logic to run inside the extension and make it harder for an attacker to inject or modify behavior after release. The model is stronger when sensitive functions stay packaged, reviewed, and contained inside the extension itself.
Why Manifest V3 Changes the Secret-Handling Risk Profile
Manifest V3 reduces risk because browser extensions no longer get the same freedom to run persistent background logic, pull in arbitrary remote code, or quietly change behaviour after review. That matters most when an extension touches secrets, because the security problem is not just storage of the secret but whether hidden or mutable code can observe, copy, or exfiltrate it later. The tighter model makes the extension easier to reason about and reduces the blast radius of a compromised update chain.
For secret-bearing extensions, the practical issue is trust continuity: the code that was reviewed at release should remain the code that handles credentials in production. When runtime behaviour can be changed remotely, security teams lose that continuity, and the extension becomes harder to audit as a stable secret-processing surface. The shift toward packaged logic also aligns better with reviewable controls and with guidance that treats non-human credentials as assets that need bounded lifecycle management, not just storage.
Manifest V3 is not a guarantee that secrets are safe, but it does remove several common ways extensions become a moving target after deployment. In practice, many teams discover extension risk only after secrets have already been exposed through over-permissive logic or update-time abuse, rather than during initial review.
How Manifest V3 Reduces Exposure in Practice
The main security gain is that the extension’s behaviour becomes more deterministic. A persistent background page can keep watching, polling, or waiting for opportunities to read secrets; a service-worker model is more constrained and easier to bring under policy. Likewise, disallowing remotely hosted code prevents a common failure mode where an extension is effectively a loader for logic that was never subjected to the same review as the published package.
That matters for secret handling because credential theft often depends on one of three mechanisms: unreviewed code paths, broad access scope, or post-release modification. Manifest V3 addresses the first and third by limiting how code enters the runtime and by narrowing what can run continuously in the browser. It does not solve poor secret design. If an extension stores long-lived API keys, grants excessive host permissions, or forwards tokens to external services without strong justification, the risk remains material even under the newer model.
For practitioners, the useful mental model is that Manifest V3 reduces the number of places where trust can drift. Security review is easier when the package is self-contained, the permissions are explicit, and the runtime cannot silently fetch new logic. That is why the model is especially relevant for extensions that perform authentication, automate browser sessions, or read data from pages that may include session tokens or other sensitive material. The OWASP Non-Human Identity Top 10 is useful here because it frames secrets as managed identities with lifecycle risk, not just strings in a browser store.
- Keep secret access in the smallest possible code path and avoid broad page scraping when a targeted API call will do.
- Prefer short-lived tokens or delegated sessions over durable credentials embedded in extension logic.
- Review every host permission as if it were an access grant, because in practice it is.
- Assume that any runtime code fetch turns the extension back into a mutable trust boundary.
These controls tend to break down when an extension is used as a general-purpose automation layer across many sites, because permission creep and page variability quickly reintroduce the same exposure Manifest V3 was meant to constrain.
Common Edge Cases and What Still Needs Care
Tighter extension rules often increase engineering friction, requiring teams to balance safer packaging against the operational convenience of dynamic behaviour. That tradeoff is real when an extension needs to support many environments, fast policy changes, or complex browser workflows.
Best practice is evolving around where secrets should live in this model. There is no universal standard for whether a browser extension should ever hold a bearer token directly, but current guidance strongly favours reducing secret lifetime, scoping access narrowly, and avoiding any design that treats the extension as a durable vault. If the extension must interact with secrets, its weakest point is usually not storage alone but the combination of host permissions, DOM access, and update channel trust.
One practical pattern is to keep the extension as a thin interaction layer and move secret issuance, rotation, and revocation to a separate control plane. The browser component then becomes a bounded consumer of ephemeral credentials rather than the owner of long-lived ones. This is especially important because browser extensions often run in user contexts that mix personal browsing, enterprise sessions, and third-party content. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is a helpful reference when deciding whether a secret should be long-lived at all.
Where teams overestimate Manifest V3 is in assuming that a safer extension platform makes secret governance optional. It does not. It only narrows the attack surface; the remaining risk still depends on whether the secret is short-lived, narrowly scoped, and impossible to repurpose outside the intended workflow.
Risk and Threat Considerations
Extensions that handle secrets create concentrated exposure because they sit close to authenticated browser sessions, sensitive page content, and user-approved permissions. If that extension is compromised, updated maliciously, or over-broadly authorised, the attacker can often move from code execution to credential capture with very little friction.
Failure mechanism: The main failure chain is trust abuse through persistent or remotely changeable logic. A legacy extension model can hide credential-access code in a background process or accept new functionality after release, letting hostile or unintended logic read tokens, scrape pages, or forward secrets without an obvious user-visible change.
Impact: The result is secret exposure, session hijack, or downstream account takeover, often with weak forensic clarity because the compromise happens inside a trusted browser component that already had legitimate access.
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 CIS Controls v8 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-01 — Secrets and Credential Management | Extensions handling secrets are managing machine credentials and token lifecycle. |
| NHI-03 — Authorization and Privilege Scope | Manifest V3 reduces risk by narrowing extension permissions and blast radius. | |
| Recommendation — Limit extension-held secrets to short-lived, scoped credentials and rotate anything durable. Constrain extension permissions to the minimum access needed for each secret workflow. | ||
| CIS Controls v8 | 6.3 — Data Protection | Secret-handling extensions need strong protection for tokens and credentials in transit and use. |
| 5.4 — Account Management | Secret-bearing browser extensions often depend on lifecycled account or token access. | |
| Recommendation — Protect sensitive tokens in transit and prevent unnecessary exposure within browser flows. Remove dormant or overbroad credential paths that the extension no longer needs. | ||
| MITRE ATT&CK | T1218 — System Binary Proxy Execution | Remote or injected logic can abuse trusted extension execution paths similarly to trusted proxying. |
| Recommendation — Detect when trusted browser components are being used to execute unreviewed logic. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question centers on access scope and trust boundaries around secret use. |
| Recommendation — Map extension secret access to explicit identity and access boundaries rather than implicit trust. | ||
Practitioner Guidance
What to prioritise: Treat extension permissions, update channels, and secret lifetime as one control set. If any one of those is weak, the overall risk remains high even if the other two look sound.
Decision rule: If an extension needs long-lived credentials to function, redesign the workflow before expanding its permissions. If it can work with an ephemeral token or delegated session, prefer that path and keep the browser component stateless where possible.
What to verify: Confirm that the extension cannot fetch executable code at runtime, cannot widen its own access silently, and cannot retain secrets beyond the minimum useful session window. Those are the checks that separate a contained tool from a latent secret-exposure path.
Practitioner takeaway: Manifest V3 should be read as a trust-boundary improvement, not a secret-management strategy; the safest design still keeps secrets short-lived, narrowly scoped, and outside any browser component that does not absolutely need to own them.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
