Browser and identity attacks now define modern SaaS compromise

At a glance

What this is: Push Security rebrands its SaaS attack matrix around browser and identity attacks, arguing that initial access now dominates the modern compromise path.

Why it matters: IAM teams need to treat browser-mediated identity abuse as a governance problem across NHI, human SSO, and emerging agentic access flows, not as an endpoint or SaaS-only issue.

By the numbers:

• Tycoon 2FA alone accounted for 62% of phishing detected by Microsoft and over 64,000 confirmed incidents.
• Microsoft reported ClickFix as the most common initial access vector in 2025, accounting for 47% of observed attacks.
• CrowdStrike documented a 563% increase in fake CAPTCHA lures, a top ClickFix style.

👉 Read Push Security's analysis of browser and identity attacks in SaaS compromise

Context

Browser-based identity attacks now sit at the front door of cloud compromise, because attackers increasingly win initial access before any SaaS application logic or endpoint control can help. The practical problem is not just phishing volume, but the way identity compromise is now brokered through the browser, through consent flows, device codes, extension abuse, and session theft.

That shift matters for IAM because the control plane is no longer limited to login pages and directory settings. It now includes the browser session, the authorization flow, the shared account ecosystem, and the way credentials are reused or replayed across applications and services.

Key questions

Q: How should security teams govern browser-based identity attacks in cloud environments?

A: Treat the browser as part of the identity control plane. Teams should monitor consent grants, device authorization flows, session reuse, and extension behaviour, because those are now common entry points for identity abuse. The goal is to detect when a legitimate session is being turned into unauthorised access before the attacker reaches cloud applications.

Q: Why do browser attacks create more risk than traditional phishing for IAM teams?

A: Browser attacks often capture valid sessions, consents, or device-code approvals instead of passwords, so they bypass some classic authentication controls. That makes them harder to detect and easier to replay across cloud services. IAM teams should assume that a successful browser-based interaction can produce real access even when credentials are never typed.

Q: What do security teams get wrong about device code phishing?

A: They often treat it like a niche phishing variant, when it is really an authorization abuse pattern. The user may already be authenticated, and the attacker simply needs the victim to complete a legitimate-looking code flow. Controls should focus on limiting the use of device authorization and watching for unusual client and account pairings.

Q: What should teams do when browser extensions can access identity workflows?

A: They should manage extensions like third-party software with identity reach, not like harmless productivity add-ons. That means approving what can be installed, tracking ownership changes, and reviewing whether an extension can read or modify authenticated web sessions. If an extension touches identity flows, it belongs in governance and monitoring scope.

Technical breakdown

Browser-mediated initial access and identity capture

The article’s core technical point is that the browser has become the primary control point for initial access, even when the final payload executes elsewhere. AiTM phishing, device code phishing, OAuth consent abuse, and ClickFix all exploit the user’s authenticated browser context to obtain tokens, sessions, or delegated access without needing to break application code. That makes browser-based identity attacks structurally different from endpoint malware or classic SaaS exploitation. The attacker is not just stealing credentials, but hijacking the trust relationship between browser, identity provider, and application.

Practical implication: treat the browser as part of the identity perimeter and monitor for session, consent, and token abuse patterns.

Device code phishing and authorization flow abuse

Device code phishing exploits the OAuth device authorization flow rather than the normal login page. The victim is often already authenticated in a browser, then completes the authorization step by entering a code and selecting an account, which can bypass password and MFA prompts entirely. This matters because the attack does not depend on cracking credentials; it depends on getting the user to approve a legitimate-looking authorization exchange. The result is valid access issued through the identity stack itself, which is why standard login protections can miss the abuse.

Practical implication: restrict and monitor device authorization flows, especially where browser sessions can be reused across managed and unmanaged devices.

Malicious extensions as a supply chain entry point

Browser extensions have become an industrialised identity attack vector because they inherit broad session visibility and, in some cases, direct access to web content, tokens, and workflow data. The article describes extension compromise paths that include developer account takeover, ownership transfer abuse, and the creation of legitimate-looking tools that are later weaponised. That creates a post-installation trust problem: once an extension is present, it can operate inside the browser boundary that many security stacks treat as implicitly trusted. The attack surface is therefore the extension lifecycle, not just code execution.

Practical implication: govern extension approval, ownership changes, and post-installation behaviour with the same scrutiny used for privileged software distribution.

Threat narrative

Attacker objective: The attacker seeks valid browser-based identity access that can be replayed into cloud applications, enabling tenant compromise and data theft without needing endpoint exploitation.

1. Entry begins in the browser through AiTM phishing, ClickFix delivery, device code phishing, OAuth consent abuse, or a malicious extension that reaches the user’s identity session.
2. Credential access or abuse occurs when the attacker captures a session token, consent grant, device code approval, or infostealer-derived credential that can be replayed against cloud apps.
3. Impact follows when the stolen identity is used for mass tenant access, data exfiltration, or broader account takeover across SaaS and cloud services.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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 identity attacks are now the organising layer for modern cloud compromise. The article is right to move beyond a SaaS-only label because the decisive action happens before the application layer is reached. Identity, not application logic, is where attackers now concentrate effort. Practitioners should interpret this as a shift in how attack surfaces are framed, measured, and defended.

Browser-based initial access has become the identity governance choke point. Endpoint controls and post-access detection still matter, but they do not explain how the identity was obtained in the first place. The field needs to stop treating initial access as a prelude and recognise it as the main event, especially where consent, device codes, and session replay are involved. Teams should re-centre governance on browser-mediated identity states.

Session theft and consent abuse are not edge cases anymore, they are the default failure mode. The article shows that attackers increasingly bypass passwords rather than break them, which means the governance assumption that authentication is the hard part is no longer reliable. This pushes IAM, browser security, and cloud access governance into the same risk conversation. Practitioners should expect identity abuse to outpace control silos that stay application-bound.

Browser trust debt is the named concept this shift exposes. Browser trust debt is the accumulated assumption that a user’s browser session, extensions, and authorization prompts remain sufficiently trustworthy to carry identity decisions safely. That assumption fails when attackers can weaponise the browser itself as the place where identity is borrowed, approved, or replayed. The implication is that browser-layer governance now belongs in identity architecture discussions, not just in endpoint policy.

Access reviews do not solve attack paths that complete before review can begin. The article reinforces that the compromise window is shrinking to minutes or seconds, so governance models built around after-the-fact certification miss the real failure point. This does not mean access reviews are obsolete; it means they are too late to be the primary brake on browser-driven identity compromise. Practitioners should treat this as a control-plane timing problem.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Browser-mediated identity compromise connects directly to the control gap described in the 52 NHI Breaches Analysis, where identity abuse rather than malware drives breach impact.

What this signals

Browser trust debt: security programmes increasingly rely on browser sessions, extension ecosystems, and consent prompts that were never designed to carry high-assurance identity decisions. The practical signal for practitioners is that browser telemetry now belongs alongside IAM logs, not beneath them.

The category shift from SaaS attacks to browser and identity attacks also changes how teams should structure detection. Identity abuse can begin and end before a conventional post-access control ever fires, so browser-layer monitoring and cloud identity signals need to be correlated much earlier in the chain.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the browser is only one part of a broader identity exposure problem. Teams should expect browser compromise, secret reuse, and session replay to converge unless governance spans both human and non-human credentials.

For practitioners

• Map browser-mediated identity entry points Inventory where users authenticate, consent, approve device codes, and install extensions, then tie those paths to the identity provider rather than to endpoint tooling alone. Use the browser as the control boundary for detection and policy. Anchor the review on browser-mediated identity entry points.
• Constrain device authorization and consent flows Restrict device code flows to approved use cases, log every authorization grant, and alert on unusual consent patterns or unfamiliar client applications. The goal is to reduce silent replay opportunities. Add monitoring around device authorization flows.
• Govern browser extensions as supply chain assets Require approval for extension installs, track ownership changes, and continuously assess post-install behaviour for access to sessions, web content, and identity tokens. Treat abandoned or transferred extensions as elevated risk. Review browser extensions as supply chain assets.
• Harden against infostealer-fed replay Prioritise controls that reduce the usefulness of stolen sessions and credentials, including session binding, conditional access, and stronger reauthentication for sensitive operations. This matters because stolen material often fuels the next wave of browser-based compromise. Focus on infostealer-fed replay.

Key takeaways

• Modern cloud compromise increasingly begins in the browser, where identity is captured through consent, sessions, device codes, and extensions rather than through application exploitation.
• The scale of browser-driven phishing and authorization abuse shows that initial access is now the main battleground, not a preliminary step.
• Practitioners need to move browser risk into identity governance, because the controls that work after access is granted are too late to stop this attack pattern.

Key terms

• Browser trust debt: The accumulated risk created when security programmes assume the browser, its session, and its extensions are trustworthy enough to carry identity decisions. In practice, this debt grows whenever authentication, consent, and token handling are treated as separate from the browser layer that actually mediates them.
• Browser-mediated identity attack: An attack that uses the browser as the place where identity is captured, approved, or replayed rather than breaking the application directly. These attacks commonly rely on phishing, consent abuse, device code flows, or extensions to obtain valid access through legitimate identity systems.
• Consent abuse: A technique in which an attacker gains access by persuading or tricking a user into granting OAuth permissions to a malicious or compromised application. The resulting access can be highly durable because it is issued through a legitimate authorization flow, not through an obviously fraudulent login attempt.
• Device code phishing: A phishing pattern that exploits the OAuth device authorization flow by getting a victim to enter a code and approve access from a browser session. It can bypass password entry and some MFA paths because the attack relies on the user completing a real authorization step.

Deepen your knowledge

Browser-based identity governance is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with browser-led compromise paths, it is worth exploring.

This post draws on content published by Push Security: Browser & Identity Attacks Matrix. Read the original.