Every modern app has that familiar button: "Sign in with Google." Or GitHub. Or Microsoft.
OAuth 2.0 powers these flows, handling authentication for billions of users. It is elegant, convenient, and — when misconfigured — a direct path to account takeover.
Here are five real OAuth vulnerabilities that attackers exploit, drawn from actual penetration tests and published CVEs.
1. Redirect URI Manipulation
The vulnerability: OAuth works by redirecting the user back to your application with an authorization code. The redirect_uri parameter tells the authorization server where to send that code. If the server does not strictly validate this parameter, an attacker can redirect the code to their own server.
How it works:
Legitimate request:
GET /authorize?
response_type=code
&client_id=APP_ID
&redirect_uri=https://app.example.com/callback
&scope=email profile
Attacker modifies redirect_uri:
GET /authorize?
response_type=code
&client_id=APP_ID
&redirect_uri=https://evil.com/steal
&scope=email profile
If the authorization server does not perform an exact match on redirect_uri, the attacker receives the authorization code and can exchange it for an access token.
Real-world CVEs:
- Spring Security OAuth (CVE-2019-3778) — path traversal in redirect_uri
- Keycloak (CVE-2020-10770) — SSRF via redirect_uri
How to defend:
- Exact string match on redirect_uri (no wildcards, no partial matches)
- Pre-register all allowed redirect URIs
- Reject requests with unrecognized redirect_uri
2. Missing State Parameter (CSRF)
The vulnerability: The state parameter in OAuth prevents cross-site request forgery. Without it, an attacker can trick a victim into linking the attacker's account to the victim's session.
Attack scenario:
- Attacker initiates OAuth flow and captures the authorization code
- Attacker sends the callback URL (with their code) to the victim
- Victim clicks the link, and the app links the attacker's OAuth account to the victim's session
- Attacker now has access to the victim's account via their own OAuth credentials
How common? We find missing or unvalidated state parameters in about 20% of custom OAuth implementations.
How to defend:
- Always generate a cryptographically random state value
- Bind it to the user's session
- Validate it on the callback — reject if it does not match
- Use PKCE (Proof Key for Code Exchange) for additional protection
3. Token Leakage via Referer Headers
The vulnerability: After OAuth redirects back to your app with a token in the URL, if your callback page loads any external resources (analytics, CDN, ads), the browser sends the full URL — including the token — in the Referer header.
Example:
# User lands on callback page with token:
https://app.example.com/callback#access_token=eyJhbGciOi...
# Page loads Google Analytics:
GET /analytics.js HTTP/1.1
Host: google-analytics.com
Referer: https://app.example.com/callback#access_token=eyJhbGciOi...
The access token is now in Google's server logs.
How to defend:
- Use the Authorization Code flow (tokens never in URLs)
- Set
Referrer-Policy: no-referreron callback pages - Avoid loading external resources on OAuth callback endpoints
- Never use the Implicit flow in new applications
4. Device Code Phishing
The vulnerability: The OAuth Device Code flow (used by smart TVs, CLI tools) displays a code and asks the user to visit a URL and enter it. Attackers exploit this by sending phishing emails with their device code.
Attack flow:
- Attacker initiates device code flow, receives code
ABCD-1234 - Attacker sends phishing email: "Your IT department requires you to verify your account. Go to https://microsoft.com/devicelogin and enter code ABCD-1234"
- Victim visits the legitimate Microsoft URL and enters the code
- Victim authenticates with their real credentials
- Attacker's device receives the victim's access token
Why it is dangerous: The victim is authenticating on a legitimate Microsoft/Google page. There is no phishing site to detect. URL looks real. SSL certificate is real. Everything appears legitimate.
How to defend:
- Educate users: "Never enter device codes you did not generate"
- Restrict device code flow to registered devices only
- Monitor for unusual device code authentication patterns
- Apply conditional access policies
5. Scope Escalation
The vulnerability: After receiving an access token with limited scope, the attacker tries to access resources beyond what was authorized — and succeeds because the resource server does not validate scopes.
Example:
# Token was granted with scope: read:profile
# Attacker uses it to access:
GET /api/admin/users
Authorization: Bearer eyJ...
# Server returns admin data because it only checks
# if the token is valid, not what scope it has
How to defend:
- Validate scopes on every API endpoint, not just during token issuance
- Implement least-privilege scope grants
- Log and alert on scope violations
- Regular audit of scope-to-endpoint mappings
Why OAuth Misconfiguration Is So Common
OAuth 2.0 is a framework, not a protocol. The specification deliberately leaves many implementation decisions to the developer. This flexibility is its strength and its biggest security risk.
Common mistakes:
- Using example code from tutorials without hardening
- Trusting the authorization server to validate everything
- Not testing OAuth flows during security assessments
- Implementing the Implicit flow because it is "simpler"
Test Your OAuth Implementation
OAuth vulnerabilities are among the most impactful findings in web application penetration tests. A single redirect_uri bypass can lead to full account takeover of every user.
TheInsider-x.com offers free AI-powered penetration testing during our beta period. Our assessments specifically test OAuth and SSO implementations for the attack vectors described above.
Start your free security assessment →
Based on real penetration testing findings, OWASP guidelines, and published CVEs.
Part of our Threat Intelligence Briefing series.
Top comments (0)