Browser-based identity attacks expose the new SaaS blind spot

At a glance

What this is: This analysis argues that the browser has become the main battleground for identity attacks because credentials and sessions now live there.

Why it matters: It matters because IAM, NHI, and human identity controls that stop at the IdP or endpoint miss where modern account takeover actually happens.

By the numbers:

• A 1,000 user organization has over 15,000 accounts with various configurations and associated vulnerabilities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Push Security's analysis of browser-based identity attacks and SaaS blind spots

Context

Browser-based identity attacks succeed because modern enterprise access is mediated by web sessions, not by local network trust. Once credentials, session tokens, OAuth grants, or backup authentication methods are captured, the attacker can operate through the same browser path the employee uses, while legacy controls continue to inspect the wrong layers.

For IAM teams, the problem is not simply phishing volume. The governance gap is that identity controls are fragmented across hundreds of SaaS applications, with inconsistent login methods, MFA posture, and visibility into how access is actually established and reused. That makes browser telemetry and identity-aware response increasingly central to both prevention and detection.

Key questions

Q: How should security teams defend against browser-based identity attacks?

A: They should move controls closer to the browser session, where login, consent, token use, and phishing all converge. That means combining identity telemetry, session revocation, fallback-method review, and SaaS access governance. Email filtering and endpoint controls remain useful, but they cannot be the only line of defence once the browser is the execution environment.

Q: Why do traditional IAM controls miss modern account takeover?

A: Traditional IAM often assumes the decisive security event is authentication at the IdP. In practice, attackers may steal credentials, hijack sessions, or abuse OAuth flows after the initial login. If the browser is where access is actually established and reused, controls that stop at configuration data will miss the real attack path.

Q: What do security teams get wrong about phishing-resistant authentication?

A: They often treat phishing-resistant login as the end of the problem. Attackers can still use backup methods, consent abuse, token theft, or help desk social engineering to get to the same account. The correct question is whether the whole access chain is resistant, not just the primary login ceremony.

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

A: Look for reduced use of weak login paths, faster session revocation, fewer unauthorised consent grants, and visibility into suspicious browser behaviours such as unusual redirects or script activity. If the team cannot see those signals, the control is not working at the layer where the attack occurs.

Technical breakdown

Why the browser is now the identity control plane

In SaaS-heavy environments, the browser is where authentication, session creation, consent, and application access converge. That makes it the only place where a security team can observe the full chain from login method to session use, including whether the user typed credentials, copied them, or was redirected through a phishing flow. Traditional tools often see only fragments of that chain. Browser-based telemetry closes that gap by exposing page behavior, redirect paths, and interaction patterns that are invisible to IdP dashboards alone.

Practical implication: treat browser-side identity telemetry as a control source, not just a detection layer.

How stolen credentials and session tokens bypass normal controls

Credential theft does not always require malware on the target device. Attackers can harvest passwords from breach dumps, infostealer logs, malicious extensions, or phishing kits, then use them in the browser to log directly into SaaS apps. Session tokens are even more damaging because they can bypass authentication altogether and land the attacker inside an active session. That is why identity compromise increasingly looks like access reuse, not password cracking. The control weakness is not just weak authentication, but the persistence and portability of the artefacts used to resume trust.

Practical implication: focus on the lifecycle and revocability of credentials and sessions, not authentication at the point of entry alone.

Why phishing has adapted faster than email controls

Modern phishing is not a single-channel email problem. It moves across instant messaging, search ads, browser redirects, malicious SaaS links, and adversary-in-the-middle kits that capture credentials, tokens, OAuth grants, or passkeys fallback paths. The attacker goal is to get the victim to complete the final step in the browser, where the trust relationship is established. Anti-analysis features such as runtime obfuscation and CAPTCHA-style gating make these flows harder for email and network tools to inspect before the browser renders them.

Practical implication: validate whether your controls can inspect the browser session itself, not just the message that delivered the link.

Threat narrative

Attacker objective: The attacker wants durable account access inside SaaS and cloud services so they can steal data or expand control without relying on endpoint compromise.

1. Entry begins when the victim reaches a phishing page, malicious redirect, or browser-mediated credential capture flow.
2. Escalation occurs when the attacker reuses stolen credentials, session tokens, or OAuth grants to access SaaS applications directly through the browser.
3. Impact follows account takeover across cloud apps, enabling data theft, privilege abuse, ransomware staging, or broader tenant compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• New York Times breach — New York Times source code and credentials exposed via GitHub.

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 compromise has moved from endpoint intrusion to browser-mediated account takeover. The browser is now where credentials, sessions, consent, and login method decisions converge, so control strategies built around device compromise or network perimeter loss miss the real attack surface. This shift applies across human IAM and SaaS-managed non-human access alike. Practitioners should treat browser exposure as the primary identity risk boundary.

Browser visibility is the new minimum for identity governance. Identity management dashboards and MFA attestations tell teams what was configured, not how access was actually obtained or reused. That is a governance gap, not just an observability gap, because attackers exploit the delta between intended access policy and browser-executed reality. Security teams need to re-evaluate which signals are authoritative for identity assurance.

Phishing resistance is no longer a single control question. The article shows attackers downgrading to backup methods, abusing OAuth consent, and using session theft to bypass the strongest login methods. That means the effective control boundary is broader than MFA quality and includes fallback methods, consent flows, and token persistence. The practitioner conclusion is that identity assurance must be evaluated as an end-to-end chain.

Browser-based response is becoming a governance requirement, not a niche detection tactic. If the attack starts and ends inside the browser, then prevention and response must be able to inspect page behaviour, redirects, scripts, and credential handling in context. That elevates browser telemetry into the identity stack alongside IdP logs, access reviews, and SaaS governance. Teams that do not extend their governance model will keep certifying the wrong state.

Identity blast radius is now shaped by application sprawl, not just privilege design. A single user can accumulate thousands of exposed access paths across SaaS applications, each with different login methods, MFA rules, and recovery options. That makes the blast radius of one compromised identity much harder to predict. The named concept here is identity blast radius: the amount of business access that can be reached once one browser-managed identity is taken over. Practitioners should use that lens when prioritising remediation.

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.
• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
• For a broader control lens, see The 52 NHI breaches Report for real breach patterns that show how identity exposure turns into compromise.

What this signals

Browser visibility is becoming a programme-level requirement because identity abuse now happens after the login page, not before it. Teams that still anchor their operating model to MFA attestations or IdP dashboards will keep missing the session-level abuse that attackers actually exploit. That makes browser telemetry, token governance, and OAuth oversight part of the same control plane.

Identity blast radius should become a planning metric for SaaS programmes. If a single user can accumulate dozens or hundreds of app-specific login paths, then risk is not evenly distributed. Prioritise the apps and workflows where browser-based takeover would expose the widest access chain.

For teams mapping identity controls to standards, NIST SP 800-207 Zero Trust Architecture remains relevant because trust decisions must be continuously re-evaluated at the point of access. Use NIST SP 800-207 Zero Trust Architecture to justify tighter session-level verification and reduce reliance on static trust assumptions.

For practitioners

• Instrument browser-side identity telemetry Capture login method, redirect chain, page interaction, and credential handling in the browser so identity compromise can be detected where it actually happens.
• Inventory fallback authentication paths Map where users can downgrade from phishing-resistant methods to weaker recovery or backup login options, then remove the downgrade path wherever business risk is high.
• Prioritise session revocation workflows Ensure stolen tokens and active sessions can be invalidated quickly across SaaS applications, because browser-based takeover often bypasses password resets.
• Review OAuth and consent exposure Audit delegated access, consent grants, and third-party app connections, especially where users can approve access from the browser without strong admin visibility.

Key takeaways

• Browser-mediated account takeover is now a primary identity threat because credentials, sessions, and consent all converge there.
• The scale problem is structural, with SaaS sprawl creating thousands of app-specific access paths that legacy IAM views cannot fully see.
• Controls that do not inspect browser behaviour, session persistence, and fallback authentication will remain blind to the attack path attackers actually use.

Key terms

• Browser-mediated identity attack: An identity attack that is executed through the web browser rather than by direct network intrusion or local endpoint compromise. The browser becomes the place where credentials are entered, sessions are resumed, consent is granted, and access is ultimately abused.
• Session token hijacking: The theft and reuse of an active authentication token so an attacker can enter an application without repeating the normal login process. It matters because a valid session can outlive the original password and bypass controls that only protect the sign-in step.
• Identity blast radius: The amount of business access that becomes reachable once one identity is compromised. In SaaS-heavy environments this includes multiple apps, login methods, and recovery paths, so a single takeover can expose more of the estate than teams expect.

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: how attacks have moved from endpoints and internal networks to the browser. Read the original.