Went through an article on an OAuth/OIDC attack - sharing the takeaways.
The problem
Common belief: follow "best practices" - BFF, HttpOnly cookies, PKCE - and your app is protected against authorization theft. In practice, it's not.
How the attack works
If an attacker can run JS on your app's page (via XSS, a compromised dependency, or a malicious extension):
The user has an active IdP session (SSO) - authorization happens silently.
The attacker secretly (hidden iframe/window) launches their own OAuth flow in the victim's browser.
The browser auto-completes it and receives an authorization code.
The attacker intercepts that code from the location before the app processes it.
From their own environment, they exchange the code for a session - gaining access as the user.
They don't need the victim's existing tokens, just a parallel flow of their own.
Why usual defenses don't help
HttpOnly cookies: code is stolen from the auth flow itself, not a cookie.
BFF: just moves tokens to the server; the API is still reachable via the session the attacker gets.
PKCE: the attacker can start their own cycle with their own parameters and plug the stolen code in.
RFC 9700 and FAPI 2.0 both acknowledge that for redirect-based flows, no complete protection exists once the authorization response leaks.
What actually works
Form Post Response Mode: the authorization server sends the code via a hidden HTML form (POST) directly to the backend, bypassing the browser/JS entirely. Nothing left to intercept.
Other measures (defense in depth, not silver bullets):
baseline XSS protection
blocking iframe embedding (CSP: frame-ancestors, frame-src)
requiring explicit user interaction
binding the code to IP/device fingerprint
separate subdomain for redirect URI
Why it matters
Not a new attack, but rarely discussed - standards' threat models often exclude such a "powerful" attacker to keep requirements manageable. XSS isn't rare in practice, so the attack stays applicable.
Takeaway: buzzwords like confidential client, BFF, PKCE, HttpOnly create a sense of security but don't replace understanding what each one actually protects against. Threat-model your own app before trusting a checklist.
Top comments (0)