Browser-based attacks are exploiting identity gaps in SaaS apps

At a glance

What this is: This is a browser-attack analysis showing that SaaS compromise now often happens through the browser, where phishing, consent abuse, extensions, and stolen sessions converge.

Why it matters: It matters because IAM and NHI programmes can no longer rely only on IdP logs, email controls, or endpoint tooling when the real abuse path is browser-visible identity and session activity.

Context

Browser-based attacks are security failures that play out where users log into and use SaaS applications, not just where endpoints or email filters see activity. In this model, the browser becomes the operational control point for identity abuse, session theft, and consent manipulation across third-party business apps.

The governance gap is visibility. Traditional IAM and endpoint controls often know who authenticated at the IdP, but not how the session was captured, how an OAuth grant was approved, or whether a browser extension or copied command changed the risk state after sign-in.

For identity teams, that shifts the problem from authentication alone to post-authentication behaviour across SaaS, browser sessions, and app permissions. The article’s central point is that modern attacks exploit the space between successful login and trustworthy use, which is where many controls still thin out.

Key questions

Q: What breaks when organisations do not have visibility into browser activity on unmanaged identities?

A: Without browser visibility, teams lose context on who accessed what, from where, and through which app or session. That makes it much harder to spot compromised credentials, shadow SaaS use, and suspicious access patterns. Response slows because investigators lack the telemetry needed to separate normal work from identity-driven attack activity.

Q: Why do attack vectors keep working even when MFA is deployed?

A: MFA blocks some credential theft, but it does not stop every path that attackers use. Session hijacking, misconfigurations, over-privileged accounts, and inherited trust can all bypass the value of a strong login. Teams need controls that govern what happens after authentication succeeds, not just before it.

Q: What are the warning signs that a SaaS access model is too browser-blind?

A: Common signs include unknown OAuth integrations, unmanaged extensions, local logins that do not enforce MFA, and an inability to explain how a user session was captured or reused. If those events are only visible after compromise, the programme is reacting too late to prevent browser-driven abuse.

Q: How should IAM teams respond when SaaS abuse happens through the browser?

A: They should treat the browser as part of the identity control plane and align app access governance, session monitoring, and response workflows around it. That means reviewing permissions, extension risk, and session behaviour together instead of separating browser threats from identity governance.

Technical breakdown

Why phishing now ends in session theft, not just credential capture

Modern phishing has moved beyond password capture. Attacker-in-the-middle kits proxy the victim’s login to the real service, so the attacker can capture the authenticated session after MFA completes. That makes the browser the decisive environment because the login, token handoff, and session reuse all happen there. The article also points to obfuscation, bot protection, and rotating infrastructure that weaken email and network-layer defenses. This is not just a delivery problem. It is an identity problem in which the browser is the place where trust is converted into a reusable session.

Practical implication: monitor browser session behaviour, not only IdP authentication events, when phishing resistance and session theft are part of the threat model.

How malicious OAuth grants bypass normal login controls

Consent phishing works by getting a user to authorize an attacker-controlled app, which gives the attacker access through OAuth scopes rather than through a password prompt. Because the user is approving access inside the SaaS application itself, the attack can sidestep controls that focus on the sign-in ceremony, including phishing-resistant MFA in some flows. The security issue is not broken authentication at the IdP. It is unauthorized delegation inside the target application, where tenant settings, app permissions, and user consent rules determine how much access the attacker receives.

Practical implication: govern OAuth grants as a distinct control surface, and review app permissions as seriously as you review account authentication settings.

Why browser extensions and ClickFix turn the browser into an execution layer

Browser extensions extend trust far beyond the page that the user is visiting. A malicious extension can observe logins, read session cookies, modify content, and capture data from the browser context. ClickFix and similar copy-and-paste lures push the browser one step further by using a page to trick the user into executing commands on the endpoint. In both cases, the browser is no longer just a display surface. It becomes the bridge between user intent, code execution, and credential theft, which is why browser-level telemetry exposes risk earlier than endpoint-only tools in many cases.

Practical implication: inventory extensions, restrict privileged permissions, and correlate browser events with endpoint execution signals before assuming the browser is low-risk.

Threat narrative

Attacker objective: The attacker wants authenticated access to business apps and data without needing to defeat the SaaS control plane directly.

1. Entry begins in the browser through phishing, malicious links, copy-and-paste lures, or consent prompts that look routine to the user.
2. Credential or session access follows when the attacker captures a token, obtains an OAuth grant, or uses the browser context to harvest cookies and stored credentials.
3. Escalation occurs when the attacker reuses the session, abuses the granted scopes, or persists through a malicious extension that can observe future logins.
4. Impact is compromise of SaaS applications and the business data inside them, often followed by theft, extortion, or broader account takeover.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The browser is now an identity enforcement layer, not just a user interface. The article shows that authentication, consent, extension trust, and session reuse now converge in the browser. That means IAM teams cannot treat browser activity as outside identity governance, because the abuse path often starts after the IdP has already said yes. The practical conclusion is that browser-visible identity events now belong in the control plane.

Identity programmes that stop at sign-in are missing the attack that actually matters. Phishing-resistant MFA helps only when the attacker must complete a conventional login. Consent phishing, session theft, and malicious extensions move the trust decision elsewhere, into in-app authorization and browser context. That changes the governance problem from proving who signed in to proving what the user approved and what the browser later allowed. Practitioners should treat post-authentication abuse as a first-class identity risk.

Browser telemetry is becoming the missing source of truth for SaaS governance. The article’s strongest point is that SSO coverage and IdP logs do not reveal ghost logins, risky OAuth grants, or browser-level session hijacking. The browser sees the actual use path across apps that security teams often do not centrally manage. For IAM and NHI teams, that means governance increasingly depends on visibility where the identity is actively exercised, not just where it is issued.

Browser-based attack detection collapses the traditional split between app security and identity security. The same browser can reveal phishing, extension abuse, unauthorized OAuth grants, and stolen session behaviour in one workflow. That is a material shift for the category because the control problem is no longer isolated to email, endpoint, or SaaS admin consoles. The practitioner takeaway is to align app access governance, session monitoring, and browser-level response as one operating model.

Session trust debt is the right name for this problem. Once an attacker captures a browser session or an OAuth grant, the session often remains valid longer than the security team expects. The article shows that the real exposure window is not the login event but the lifetime of the trusted session and delegated app access. Teams should therefore reframe browser compromise as durable trust debt, not a one-time authentication failure.

What this signals

Browser session trust is now the governance boundary: security teams should assume that valid authentication does not equal trustworthy access. The practical challenge is to detect when a browser session becomes a delegated abuse path, especially across SaaS apps that were never centrally managed.

Browser-based compromise shifts identity risk from the login screen to the lifetime of the session and the permissions attached to it. That means programmes built around IdP events alone will miss the most consequential part of the attack chain.

For practitioners

• Map browser-visible identity events Correlate logins, consent grants, extension activity, and session reuse so you can see where access is being exercised after authentication.
• Review OAuth grants as governance objects Treat app consent and tenant permissions as part of identity governance, with periodic review for risky scopes and unknown integrations.
• Inventory and restrict browser extensions Block or pre-approve extensions with broad website access, cookie access, or tab and network control before they become an identity exposure path.
• Detect suspicious browser execution patterns Look for copied commands, unexpected clipboard use, and browser events that precede endpoint code execution or credential theft.
• Find ghost logins and MFA gaps Identify local logins that still accept passwords without MFA and prioritize the apps where browser-observed sign-ins do not match corporate identity policy.

Key takeaways

• Browser-driven abuse now reaches SaaS through phishing, consent prompts, extensions, and copied-command lures rather than only through classic password theft.
• The main evidence in the article is that attackers are already using session hijacking, malicious OAuth grants, and stolen credentials against widely used business apps.
• Identity teams need browser-visible telemetry, tighter OAuth governance, and extension control if they want to reduce the gap between successful login and trustworthy use.

Key terms

• Browser-Based Attack Vector: A browser-based attack vector is a path by which malware, ransomware, or other threats reach users through web activity and browser sessions. It matters because employees increasingly rely on browsers for SaaS and private applications, making browser security a core part of endpoint and identity protection.
• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
• Ghost Login: A ghost login is a direct authentication path that remains active after an organisation believes it has moved to central single sign-on. It creates a parallel trust model that can still accept passwords, so the identity team sees one policy posture while attackers exploit another.

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.