Browser identity attacks are outpacing legacy security controls

At a glance

What this is: This recap argues that modern attacks are dominated by identity abuse in the browser, not classic software exploitation, with session theft and post-authentication tactics doing most of the damage.

Why it matters: IAM teams need to treat browser sessions, OAuth grants, and non-human access paths as first-class control points because the attacker objective has shifted from breaking in to logging in.

By the numbers:

• CrowdStrike's 2026 Global Threat Report found that 82% of attack detections are now malware-free.
• Google/Mandiant recently reported that identity issues were the initial access vector in 83% of cloud-related incidents.

👉 Read Push Security's recap of security theatre vs. security that works

Context

Browser attacks matter because they let adversaries use normal authentication flows, session tokens, and trusted extensions instead of exploiting code. That shifts the control problem from patching software to governing identity and access paths that appear legitimate to the browser and the SaaS stack.

For IAM, this is an NHI and human identity story at the same time. The same browser session that gives a person access can also be the bridge into OAuth tokens, delegated access, and downstream service activity, which means identity governance has to extend beyond the login event.

The article’s central message is that many organisations are still funding endpoint and network controls for an attack model that has moved on. That gap is typical, not exceptional, in environments where browser trust, session persistence, and access review processes were designed separately.

Key questions

Q: How should security teams respond when browser sessions survive token revocation?

A: They should treat session termination as a separate control from IdP token revocation and test it against the actual SaaS applications in use. The key question is not whether the identity provider invalidated a token, but whether downstream sessions, cookies, and delegated grants are still active after containment.

Q: Why do browser-based attacks bypass many IAM controls?

A: They exploit the point after authentication succeeds. If the attacker steals a session, abuses consent, or rides a trusted extension, the IAM control that only validated the login has already done its job while the real compromise continues elsewhere.

Q: How can organisations tell whether their browser security controls are working?

A: Look for visibility into post-authentication behaviour, not just blocked logins. If you cannot see extension drift, unexpected consent grants, or session reuse across SaaS applications, your controls are missing the part of the attack that matters most.

Q: What is the difference between MFA coverage and session control?

A: MFA controls how a user proves identity at login, while session control governs what happens after that login. If session tokens, OAuth grants, or browser cookies remain valid after revocation, MFA may be strong while the real access path stays open.

Technical breakdown

Malware-free intrusion paths in the browser

Modern attackers increasingly use legitimate browser functionality rather than payload delivery. That includes credential stuffing, phishing, consent abuse, device code phishing, session cookie theft, and AiTM proxying that captures both authentication factors and the resulting session. The browser becomes the execution environment, which means the attack often leaves little malware evidence and looks like valid user activity from the perspective of the IdP and SaaS application. This is why exploit-centric detection misses a large share of the problem: the adversary is not trying to break the app, only to inherit its trust.

Practical implication: tune detection for identity behaviour, session anomalies, and delegated access rather than waiting for malware signatures.

Why MFA coverage still leaves a usable attack surface

MFA reduces risk, but it does not eliminate authentication abuse. Coverage gaps persist because some applications do not support strong methods, some user populations are not fully migrated, and some attacks bypass authentication after it succeeds. Once a session exists, token theft and cookie reuse can preserve access even when the initial login was protected. This is why browser-based attacks are so effective: they attack the seam between authentication and session control, where many programmes assume MFA has already done enough.

Practical implication: measure post-authentication controls, not just MFA rollout, and verify what your IdP actually revokes downstream.

Browser extensions as persistent delegated access

Extensions operate with broad, often necessary permissions, which makes them a durable privilege channel inside the browser. That channel is attractive to attackers because a legitimate extension can later be compromised, sold, or updated maliciously, turning an approved tool into a data-harvesting or session-abuse mechanism. The security challenge is governance, not just install-time review. If an organisation only approves an extension once, it is blind to the changes that happen after deployment, including permission creep and malicious updates.

Practical implication: include extensions in access governance and monitor updates, permissions, and behavioural drift continuously.

Threat narrative

Attacker objective: The attacker’s objective is to convert a single browser login into durable, multi-application access that survives the initial authentication event and enables rapid data or account abuse.

1. Entry begins with browser-adjacent identity abuse such as phishing, consent abuse, ClickFix, or credential harvesting that gives the attacker a legitimate login path.
2. Escalation happens when the attacker captures session tokens, OAuth grants, or downstream SaaS sessions that remain valid after the original authentication event.
3. Impact follows when the attacker uses that valid access to reach cloud workloads, sensitive data, or additional accounts before defenders can contain the session.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

Identity trust has shifted from the network edge into the browser session. That matters because the browser now mediates authentication, consent, extensions, and downstream SaaS access in one place. Security programmes that still treat the browser as a client rather than an identity control plane miss the point. The practitioner conclusion is that browser-layer identity telemetry belongs in IAM governance, not only in endpoint operations.

Browser-based attack tradecraft exposes a standing session privilege problem, not just a phishing problem. Once an attacker inherits a session, the control failure is no longer whether a user clicked a link but whether the session was bounded, observed, and revocable in practice. That is the same governance challenge seen in NHI programmes when tokens outlive their intended use. The practitioner conclusion is to treat session persistence as an access entitlement with lifecycle risk.

Browser extensions create delegated identity risk that most approval processes still ignore. An extension can start as legitimate access and later become a standing data and session collection point through updates, purchases, or compromised developer accounts. That is a governance failure because the permission model is stable only at install time, while the risk changes after deployment. The practitioner conclusion is that approval without continuous review is not control, it is a snapshot.

Ephemeral credential trust debt: security teams assume that a short-lived token, consent grant, or browser session is safe because it is temporary. That assumption fails when attackers can chain access quickly enough to extract value before expiry, or when downstream SaaS sessions remain live after upstream revocation. The implication is not that teams should simply add more controls, but that they should stop relying on temporary access as a proof of safety.

Browser attacks collapse the boundary between human identity and non-human identity governance. The same browser can mediate a human login, an OAuth grant, a session cookie, and automated downstream activity that behaves like NHI access. That means IAM, PAM, and NHI teams cannot stay in separate operational lanes. The practitioner conclusion is to govern browser-mediated access as one identity fabric with distinct actor types, not as isolated tools.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The control question now is not whether AI agents will spread, but whether identity governance can see and constrain their access before browser-adjacent abuse becomes the default path, as explored in AI Agents: The New Attack Surface report.

What this signals

Browser trust is becoming an identity governance problem, not just a detection problem. As sessions, consent grants, and extensions become the real attack surface, teams need a control model that can explain who or what was acting, under what authority, and for how long. That is where browser telemetry, IAM, and NHI oversight begin to converge, and where most programmes still have blind spots.

With 52% of companies unable to track and audit the data their AI agents access, per AI Agents: The New Attack Surface report, the same visibility gap that hurts browser security also hurts emerging agent governance. If organisations cannot see access paths clearly, they cannot distinguish legitimate automation from identity abuse.

Ephemeral credential trust debt: this is the pattern where temporary access looks safe on paper but still becomes exploitable in practice because downstream sessions and delegated grants outlive the original control. Teams should prepare for a governance model that measures residual access after revocation, not just initial authorisation, and align browser controls with the NIST Cybersecurity Framework 2.0.

For practitioners

• Instrument browser identity telemetry Collect signals on login provenance, consent grants, session reuse, extension behaviour, and unusual SaaS access so that identity abuse can be detected before broad lateral movement starts.
• Map what token revocation really kills Test the full revocation chain from IdP token invalidation to downstream SaaS session termination, then document the applications where a revoked upstream token still leaves a live session.
• Review browser extensions as delegated access Put approved extensions on a continuous review path that tracks permissions, publisher changes, and updates, because install-time approval does not reflect post-install risk.
• Treat consent grants as access entitlements Audit OAuth consents, device code flows, and SaaS delegation paths with the same discipline you apply to privileged accounts so that hidden access paths are not missed during reviews.

Key takeaways

• Browser attacks increasingly succeed by abusing identity and session trust rather than exploiting code.
• The practical benchmark is whether your programme can see, contain, and revoke downstream access after a browser login is compromised.
• Browser extensions, OAuth consents, and session persistence now belong in the same governance conversation as MFA and privileged access.

Key terms

• Browser identity attack: An attack that abuses the browser as the place where identity, consent, and session trust are negotiated. Instead of exploiting code, the attacker leverages login flows, cookies, OAuth grants, or extensions to inherit valid access and continue activity that appears legitimate to downstream systems.
• Session persistence: The tendency for access to remain valid after the original authentication event has ended or been revoked upstream. In browser-centric incidents, this is the gap between killing the login and actually terminating the live SaaS or application session that the attacker is still using.
• Delegated browser access: Access granted indirectly through a browser-mediated mechanism such as an extension, consent grant, or session token. It matters because the privilege is often broad, difficult to observe continuously, and capable of changing after approval without a fresh governance decision.
• Ephemeral credential trust debt: The hidden risk created when temporary access is assumed to be safe simply because it expires. In practice, attackers may use the credential faster than defenders can react, or the credential may open downstream sessions that outlive revocation, leaving residual access behind.

Deepen your knowledge

Browser identity attacks and session governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme around browser-layer identity risk, it is worth exploring.

This post draws on content published by Push Security: Security theatre vs. security that works, the third episode in its State of Browser Attacks series. Read the original.