TL;DR: 49% of organisations suffered a successful browser-based attack in the last 12 months, according to Push Security and Omdia, with browser-originated incidents now accounting for roughly 37% of all security incidents among affected organisations. Browser controls built around visibility outside the session no longer match where phishing, credential theft, token abuse, and data loss actually occur.
At a glance
What this is: This is a research-backed analysis of browser security showing that the browser session has become the primary enterprise attack surface, with successful attacks, incident share, and investment all moving upward.
Why it matters: For IAM and security teams, the finding matters because identity actions, session abuse, AI tool use, and data leakage are now happening inside the browser where traditional network and endpoint controls often lack full context.
By the numbers:
- 49% of organisations suffered a successful browser-based attack in the last 12 months.
- Browser-originated incidents account for roughly 37% of all security incidents among affected organisations.
- 88% of respondents rank browser security as at least a top-five security priority.
- 85% of respondents expect to increase browser security spend over the next 12 to 24 months.
Context
Browser security is the control plane that sits closest to the user’s actual work. In practice, that means the browser session now carries the credential entry, token exchange, AI prompt, extension execution, and data movement that older controls were designed to observe only indirectly.
The governance gap is not simply visibility. Most security programmes still treat browser activity as a downstream signal from email, network, or endpoint tooling, but the article shows that the attack, the identity action, and the loss event increasingly happen inside the browser itself.
For IAM and NHI practitioners, this shifts browser security from a web protection concern to a session governance issue. The programme question is no longer only who authenticated, but what happened after authentication inside the session boundary.
Key questions
Q: What breaks when browser security is treated as just web filtering?
A: Visibility breaks first. Web filtering can show that a user reached a destination, but it cannot reliably show credential entry, token creation, extension behaviour, or in-session data movement. That leaves the highest-risk activity invisible at the point where attacks are actually succeeding, so control decisions are based on partial evidence.
Q: Why do browser sessions increase phishing and AiTM risk?
A: Because the browser session is where the user authenticates, the token is minted, and the attacker can capture the live interaction. AiTM and phishing succeed when the control boundary sits outside the session, leaving defenders without the context needed to distinguish a real login from a proxied one.
Q: How should teams enforce GenAI policy in the browser?
A: They should enforce it at the session layer, where they can see the prompt, the destination, and the data entered by the user. Policy without browser-layer instrumentation cannot tell whether sensitive content was pasted into an unsanctioned AI tool, so compliance becomes guesswork rather than control.
Q: Should security teams treat browser extensions like third-party access?
A: Yes. A browser extension can function like delegated third-party code because it inherits access to the user session and can change behaviour after initial approval. That makes lifecycle control important. Teams should evaluate who publishes the extension, what permissions it requests, and how quickly it can be removed if the trust relationship changes.
Technical breakdown
Why browser sessions are now the control boundary
A browser session is the live execution context where a user interacts with an application, submits credentials, authorises access, and moves data. That makes it materially different from network traffic inspection or endpoint telemetry, which can show that something happened without showing the exact interaction inside the tab. In this article’s threat pattern, phishing, AiTM, malicious extensions, credential theft, and data leakage all occur within that session context. The security implication is that the browser has become the point where identity, content, and action converge, which is why browser-layer telemetry has higher evidentiary value than perimeter-only controls.
Practical implication: treat the browser session as a governed security boundary, not just a rendering layer.
Why AI usage creates browser-level governance problems
AI use in the browser changes both the threat model and the control problem. Users paste sensitive data into public GenAI tools, attackers build fake AI login pages, and AI-assisted phishing lowers the cost of high-volume, high-conviction social engineering. The browser is the common substrate for all of that activity. Secure web gateways can show destination and traffic metadata, but they cannot reliably tell whether a user pasted source code into a prompt or whether a page is a reverse-proxy credential capture flow. That gap is why policy statements about unsanctioned AI usage often fail to become enforceable controls.
Practical implication: enforce GenAI policy at the browser layer where the prompt, session, and data movement are visible.
Why browser extensions behave like supply chain risk inside the session
Browser extensions are not passive add-ons. They execute code inside the browser environment, can read page content, and often inherit user context that includes sensitive applications and session state. That makes malicious or vulnerable extensions a supply chain and runtime risk at once. Unlike a traditional vulnerability in a web app, the extension risk lives where the user’s authenticated session already exists, which means compromise does not always require a new login or a separate foothold. The result is a control problem that sits between application security, endpoint oversight, and identity governance.
Practical implication: inventory extension behaviour as part of session governance, not as a separate browser hygiene task.
Threat narrative
Attacker objective: The attacker wants to turn a legitimate browser interaction into authenticated access, session control, or data exfiltration without tripping traditional perimeter controls.
- Entry begins inside the browser when a user reaches a phishing page, fake AI login page, or malicious extension flow that looks like a normal work interaction.
- Credential harvesting follows through the session as the victim enters credentials, accepts a prompt, or creates a live token exchange that the attacker can reuse.
- Impact occurs when the attacker replays the captured session, abuses browser-originated access, or exfiltrates data through the same in-session path the user trusted.
NHI Mgmt Group analysis
Browser security has become a session governance problem, not a web filtering problem. The article’s strongest signal is not simply that attacks are rising, but that the attack, the identity action, and the data loss now happen inside the same browser session. That collapses the old separation between access control and content control. Practitioners should read this as a boundary shift: the browser is now where governance must observe and intervene.
Browser-level telemetry is the missing control surface for modern identity abuse. Network and endpoint tools can still be useful, but they do not see the credential entry, token creation, or prompt-level data disclosure that defines the current attack path. This is especially material for IAM teams because browser session events are now part of the identity lifecycle, not just the access layer. The programme implication is that session evidence must become first-class governance data.
GenAI policy is unenforceable without browser-layer controls. The article shows a common gap: organisations may sanction or ban specific AI tools, yet still lack the ability to see what users actually do inside the session. That makes browser controls the enforcement point for data handling, prompt governance, and unsanctioned tool use. The implication is that policy language without session instrumentation is not governance, only intent.
Browser extensions now sit inside the identity trust chain. Malicious or vulnerable extensions can observe and manipulate a user’s authenticated work session, which means they should be governed alongside privileged access pathways. This is where browser security intersects with identity assurance, because an extension can effectively become part of the access path. Practitioners should treat extension behaviour as a governed trust dependency, not an endpoint side issue.
Browser security buying is moving from point controls to operational control planes. The report shows organisations want integration with existing tools, GenAI controls, and central policy enforcement, which points to a market that is converging on session-level instrumentation rather than browser replacement. That tells us the category is maturing around operational governance, not just threat detection. Security teams should evaluate browser controls by how directly they govern the session boundary.
What this signals
Session visibility is now the difference between policy and enforcement. Browser controls matter because they see the action that happens after authentication, not just the request that reached the site. For security teams, that means browser-layer telemetry should be evaluated as part of identity governance and not only as a threat-detection input.
Browser session governance is becoming a shared responsibility across IAM, SecOps, and data protection. The control problem spans who authenticated, what they did, and whether sensitive data left through an approved or unsanctioned path. Teams that leave those ownership lines unclear will continue to miss browser-originated abuse until after damage occurs.
For practitioners
- Instrument browser sessions as a control boundary Capture session-level events for credential entry, prompt use, extension behaviour, and file movement so the programme can see what happens after authentication.
- Enforce GenAI policy where users actually work Move from policy statements to browser-layer controls that can distinguish sanctioned from unsanctioned AI usage and identify prompt-time data exposure.
- Review browser extensions as part of access governance Inventory extension permissions, execution behaviour, and exposure to authenticated applications because extensions operate inside the trusted session.
- Prioritise browser-originated incident detection Tune detection and response around phishing, AiTM, credential theft, and session hijack patterns that begin and end within the browser.
- Align browser controls with identity and data teams Treat browser security as a shared operating model for IAM, SecOps, and data protection so telemetry, response, and policy ownership are not split across silos.
Key takeaways
- Browser security has shifted from an edge concern to a session governance problem because the attack, the identity action, and the data loss now happen inside the browser.
- The report shows both scale and urgency, with 49% of organisations reporting a successful browser-based attack and 88% ranking browser security among their top five priorities.
- Security teams need browser-layer visibility, because policy and perimeter tooling alone cannot reliably govern phishing, AiTM, extension abuse, or in-session data leakage.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Credential theft, cookie theft, and token exposure are central browser-session attack patterns here. |
| NHI-10 — Human Use of NHI | The article links browser sessions, identity actions, and unsanctioned AI use to governed access behaviour. | |
| Recommendation — Apply NHI-02 controls to detect and block secret exposure in browser sessions and AI prompt workflows. Govern browser-mediated identity actions under NHI-10 when users interact with tokens, prompts, and browser-based access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Browser sessions now carry the operational evidence of who accessed what and how they used it. |
| Recommendation — Use PR.AA-05 to align browser-session governance with identity and authorization decisions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article centres on browser-based credential theft, session hijack, and follow-on misuse. |
| Recommendation — Map browser-session abuse to TA0006 and TA0008 to improve detection around credential capture and post-login movement. | ||
Key terms
- Browser Session Governance: Browser session governance is the discipline of controlling and auditing what happens after authentication inside a live browser session. It matters because modern work often continues well past login, where data movement, AI prompts, and extension use create the real risk.
- Session-level telemetry: Security data captured from inside the browser session, such as logins, clipboard events, file transfers, extension changes, and OAuth consents. It is more useful than alert-only reporting because it preserves the context needed to explain how identity and data risks developed.
- AiTM Attack: An AiTM attack, or adversary-in-the-middle attack, intercepts a user’s browser session to capture credentials or session tokens in real time. In browser-centric environments, the attacker abuses the authentication exchange itself rather than exploiting the application from outside the session.
- Secure Enterprise Browser: A secure enterprise browser is a browser control model that applies security policy, monitoring, and enforcement inside the browser experience. It aims to observe and govern session behaviour directly, which makes it relevant for phishing resistance, data loss prevention, and AI use oversight.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org