OAuth Vulnerabilities
OAuth vulnerabilities are security flaws in the implementation of OAuth 2.0 authorization flows that can lead to access token theft, account takeover, or unauthorized access to protected resources.
Understanding OAuth Vulnerabilities
OAuth 2.0 is the standard protocol for delegated authorization — "Sign in with Google," "Connect with GitHub," and similar flows. While the OAuth specification is well-designed, implementation errors create vulnerabilities. The protocol's flexibility means there are many ways to configure it incorrectly.
The most common OAuth vulnerabilities include redirect URI manipulation (changing the callback URL to redirect tokens to the attacker), missing state parameter (enabling CSRF against the OAuth flow), insufficient redirect URI validation (accepting subdomain or path variations of registered URIs), authorization code interception (in mobile apps without PKCE), and insecure token storage (storing access tokens in URLs, logs, or browser history).
The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended approach for all client types. PKCE adds a cryptographic challenge that binds the authorization request to the token exchange, preventing interception attacks even if the authorization code is stolen. Without PKCE, an attacker who intercepts the authorization code (through a malicious app on mobile or a compromised redirect) can exchange it for an access token.
Scope over-provisioning is another common issue. Applications often request more OAuth permissions than they need, increasing the impact of a token compromise. Always request the minimum scopes necessary and re-request additional scopes only when the feature requiring them is used.
Why This Matters for Vibe-Coded Apps
Vibe-coded apps that use "Sign in with Google/GitHub" through AI-generated OAuth implementations are vulnerable to several common mistakes. The AI may skip the state parameter (enabling CSRF), accept any redirect URI without validation, store tokens in localStorage rather than secure httpOnly cookies, or request excessive scopes. Managed auth providers like Supabase Auth, Firebase Auth, and NextAuth handle these details correctly.
If your AI generated a custom OAuth implementation rather than using a managed provider, it is strongly recommended to switch to a well-tested library like NextAuth, Passport.js, or the managed auth from your backend platform. Custom OAuth implementations are one of the highest-risk areas for security flaws in AI-generated code.
Real-World Examples
Facebook OAuth Token Exposure (2018)
A bug in Facebook's View As feature exposed OAuth access tokens in the URL. Attackers harvested tokens affecting 50 million accounts by exploiting the interaction between the video uploader and View As feature, obtaining tokens that granted full account access.
Slack OAuth Redirect Vulnerability (2017)
A flaw in Slack's OAuth implementation allowed attackers to steal OAuth tokens by manipulating the redirect URI. The validation only checked the domain, not the full path, enabling redirects to attacker-controlled endpoints on Slack's own domain that would forward the token.
Microsoft OAuth Wildcard Redirect (2021)
Researchers discovered that Microsoft's OAuth implementation accepted wildcard subdomains in redirect URIs. By finding an XSS vulnerability on any Microsoft subdomain, attackers could redirect OAuth tokens to the vulnerable subdomain and extract them, demonstrating how OAuth and XSS vulnerabilities compound each other.
Frequently Asked Questions
What is the state parameter and why is it important?
The state parameter is a random value included in the OAuth authorization request and validated when the user returns. It prevents CSRF attacks on the OAuth flow. Without it, an attacker can initiate an OAuth flow with their own account and trick a victim into completing it, linking the attacker's external account to the victim's application account. Always generate a cryptographically random state value and verify it matches upon callback.
Should I use authorization code flow or implicit flow?
Always use the authorization code flow with PKCE. The implicit flow (where tokens are returned directly in the URL fragment) is deprecated because tokens are exposed in browser history, URL bars, Referer headers, and server logs. The authorization code flow keeps tokens out of URLs by exchanging a short-lived code for tokens via a back-channel request. PKCE adds protection even when a client secret cannot be kept confidential (SPAs, mobile apps).
Can OAuth token theft lead to account takeover?
Yes. A stolen OAuth access token grants the attacker the same permissions the token authorizes. If the token has full account access, the attacker can do everything the user can. Refresh tokens are even more dangerous because they can generate new access tokens indefinitely. Mitigation includes short access token lifetimes, refresh token rotation (invalidating old refresh tokens when new ones are issued), and binding tokens to specific client characteristics.
How does PKCE protect OAuth flows?
PKCE works by generating a random code_verifier and sending its hash (code_challenge) with the authorization request. When exchanging the authorization code for tokens, the original code_verifier is sent. The server verifies that the verifier matches the challenge. This ensures that only the party who initiated the OAuth flow can complete it — even if the authorization code is intercepted, the attacker does not have the code_verifier and cannot exchange it for tokens.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to oauth vulnerabilities and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan