Browser security is really identity security in disguise

At a glance

What this is: This analysis argues that browser security is increasingly an identity problem, because the most damaging attacks happen through legitimate login flows rather than browser exploitation.

Why it matters: It matters because IAM, NHI, and security teams need controls that see credential abuse, session theft, and OAuth consent misuse where work actually happens, not just browser hardening.

By the numbers:

• Identity weaknesses played a material role in almost 90% of Unit 42 incident response investigations.
• Credential abuse and phishing combined accounted for 38% of all breaches.
• Cloud-conscious intrusions rose 37% in 2025.
• 49% of organizations suffered a successful browser-based attack in the last 12 months.

👉 Read Push Security's analysis of browser-based identity attacks and breach risk

Context

Browser security is often framed as a software hardening problem, but the article's central claim is that the more damaging issue is identity abuse inside the browser. That matters for IAM because the browser is now where users authenticate, where sessions persist, and where attackers steal tokens, credentials, and OAuth grants.

The practical divide is between protecting the browser engine and protecting the organisation through the browser. Security teams evaluating browser controls need to ask whether the tool sees malicious login behaviour, session hijacking, and consent abuse across managed and unmanaged devices, or only device-centric exploitation that represents a smaller part of the breach picture.

Key questions

Q: How should security teams protect users in the browser without relying only on endpoint hardening?

A: They should treat the browser as an identity control point and look for phishing, adversary-in-the-middle relays, session theft, and OAuth abuse in the session itself. Endpoint hardening still matters, but it does not replace visibility into authentication behaviour, consent grants, or token replay. The goal is to detect identity misuse where work happens, not only device compromise.

Q: Why do browser-based identity attacks create more risk than browser exploitation in many enterprises?

A: Because attackers can use legitimate login flows to inherit valid access, which is cheaper and more reliable than developing browser zero-days. Once credentials or tokens are stolen, the attacker operates as the user inside SaaS and cloud applications. That makes the breach harder to distinguish from normal activity and increases the blast radius of a single compromise.

Q: What do security teams get wrong about browser security investments?

A: They often buy controls that defend the browser software, then expect those controls to stop identity theft inside the browser session. That is a category error. Teams should measure whether a tool detects credential abuse, token theft, malicious consent, and suspicious login context, because those are the attack patterns driving most modern breaches.

Q: Who should own browser-based identity risk in an enterprise?

A: Ownership should sit across IAM, security operations, and endpoint teams, because the risk spans authentication, session handling, and device posture. If browser-based attacks are only treated as endpoint issues, identity abuse will be missed. If they are only treated as IAM issues, device and browser context will be ignored. Shared ownership is the only workable model.

Technical breakdown

Browser hardening versus identity attack detection

Browser hardening tries to stop code execution inside the browser process by changing how scripts run, how sandboxes behave, or how exploits chain into the device. Identity attack detection looks at what happens during normal use: phishing pages that collect passwords, adversary-in-the-middle proxies that relay authentication in real time, and token theft that preserves the session after login. These are different technical problems. The first assumes the browser is the target. The second assumes the browser is the workplace where identity is abused after the user has already arrived. Practical implication: evaluate controls against the attack path you actually see in incident data, not against a generic browser-exploit model.

Practical implication: classify browser tooling by whether it detects runtime identity abuse, not just exploit containment.

Session hijacking, OAuth consent abuse, and legitimate flows

Modern browser-based attacks often avoid malware and exploit the legitimacy of the authentication flow itself. An attacker can phish credentials, intercept an MFA step in an adversary-in-the-middle proxy, steal a session token, or trick a user into approving a malicious OAuth application. Once the session exists, downstream SaaS access looks legitimate unless the control plane can inspect the browser interaction and correlate it to identity risk. That is why traditional endpoint or network inspection often misses the abuse: the traffic and the login both look valid. Practical implication: place detection where the authentication event and the browser session can be evaluated together.

Practical implication: add controls that observe authentication context, session integrity, and OAuth consent at runtime.

Managed and unmanaged devices expand browser exposure

Browser-centric identity attacks do not respect the managed-device boundary. If users authenticate from BYOD, contractor laptops, or personally synced browsers, a kernel agent or device-only sensor will miss part of the attack surface by design. That creates a visibility gap between where policy is written and where authentication actually happens. Browser extension telemetry can close part of that gap by following the identity across devices and browsers rather than anchoring detection to a single endpoint posture. Practical implication: assess whether your browser control strategy still works when the session starts outside corporate hardware.

Practical implication: verify that browser controls cover unmanaged and personally synced sessions, not only corporate endpoints.

Threat narrative

Attacker objective: The attacker wants to inherit legitimate identity and session authority so they can operate inside enterprise SaaS without triggering exploit-based controls.

1. Entry occurs when the attacker uses phishing, adversary-in-the-middle infrastructure, or a malicious OAuth consent flow to reach a legitimate browser session.
2. Escalation happens when credentials, MFA context, or a session token is captured and replayed into cloud or SaaS services.
3. Impact follows when the attacker operates as the user inside approved applications, enabling data access, account takeover, or follow-on lateral movement.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Browser security is now an identity governance problem, not only an endpoint problem. The article is right to separate browser exploitation from browser-based identity abuse. Once the browser becomes the primary authentication surface, the governance question shifts from 'Can the browser be compromised?' to 'Can identity misuse be seen in the session?' That is a different control philosophy, and it affects IAM, PAM, and NHI oversight alike. Practitioners should treat browser telemetry as part of identity control coverage, not as a separate product category.

Session theft has become the more durable breach path because it preserves legitimacy. A stolen password is only the beginning if the attacker can also capture the session token or relay the login in real time. That persistence inside an approved session is why browser-based attacks keep outperforming exploit-based ideas in the real world. The lesson for identity programmes is that authentication success is not security proof. Practitioners should re-evaluate any control stack that treats successful login as a low-risk event.

Identity attack kill chains now outcompete browser exploit kill chains on economics and reliability. The article's own comparison is persuasive because attackers act rationally: phishing kits, stolen credentials, and session replay are cheaper and more scalable than browser zero-days. That does not make browser hardening irrelevant, but it does make it a narrower control than many teams assume. Practitioners should align investment with the attack category that is actually producing breach volume, not the one that is easiest to market.

Browser-native identity telemetry is becoming a prerequisite for detecting shadow access. When users work across unmanaged devices, personal profiles, and multiple SaaS applications, security teams lose line of sight unless detection follows the browser session itself. That is especially relevant for shadow AI use, unsanctioned SaaS, and OAuth sprawl, where the browser is the hidden control plane. Practitioners should treat browser visibility as an identity inventory problem as much as a detection problem.

Identity blast radius is the right named concept for this category of risk. The attack does not need to own the browser engine to own the identity that uses it. Once a session or token is stolen, the blast radius is defined by the permissions already attached to that identity, including SaaS roles, OAuth grants, and downstream data access. Practitioners should read browser security through the size of the resulting identity blast radius, not through exploit prevention alone.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader baseline, read Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and over-privilege patterns that help explain browser-era identity abuse.

What this signals

Identity telemetry must become browser-native if teams want to see the real attack surface. The browser is now where users authenticate, where OAuth grants are approved, and where session theft becomes actionable. Teams that still treat the browser as an endpoint-adjacent concern will keep losing line of sight as work shifts across managed devices, personal profiles, and SaaS-first workflows.

With 1 in 4 organisations already investing in dedicated NHI security capabilities according to The State of Non-Human Identity Security, the market signal is clear: identity visibility is moving from a control add-on to a primary security requirement. Browser security programmes should be evaluated on whether they reduce identity blast radius, not only on whether they block exploits.

For practitioners

• Separate browser exploit protection from identity abuse detection Map current browser controls to the attack they actually address, then identify where phishing, AiTM, token theft, and OAuth consent abuse still pass through without meaningful visibility.
• Inventory browser-based identity exposure across managed and unmanaged devices Trace where users authenticate from BYOD, contractor endpoints, synced profiles, and secondary browsers so the programme covers the real session entry points rather than only corporate laptops.
• Correlate browser telemetry with identity events Join login context, token use, consent grants, and session anomalies so a successful authentication does not automatically count as a trusted session.
• Review OAuth consent and extension permissions as access pathways Treat third-party app grants and risky browser extensions as identity pathways that can expand privilege or enable session theft if they are compromised.

Key takeaways

• The core problem is not browser compromise alone but identity abuse inside legitimate browser sessions.
• Threat intelligence cited in the article shows that credential abuse, phishing, and cloud-conscious intrusions now dominate the breach picture.
• Practitioners should measure browser security by its ability to detect session theft, OAuth abuse, and identity misuse across managed and unmanaged devices.

Key terms

• Adversary-in-the-Middle Attack: A technique where an attacker sits between the user and the legitimate service to intercept or relay authentication in real time. The login appears valid to both sides, which allows the attacker to steal credentials, tokens, or MFA context without breaking the browser itself.
• Session Token: A temporary credential that represents an authenticated browser session after the user logs in. If stolen, it can let an attacker act as the user until the token expires or is revoked, which is why session protection is as important as password protection.
• OAuth Consent Abuse: A misuse pattern where a user is manipulated into approving a malicious third-party application that then gains access to SaaS data or actions. The abuse happens through a legitimate consent flow, so detection must focus on grant context and application risk, not only on malware.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: securing the browser vs. securing the organisation via the browser. Read the original.