OAuth State Check — Is Your Social Login CSRF-Proof?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
Without the OAuth state parameter, an attacker can link their Google or GitHub identity to a victim's account with one crafted link — then log in as the victim.
Why AI tools generate it
AI scaffolds hand-roll OAuth with a redirect and a callback; the state parameter is the piece tutorials skip because login works without it.
How DevMeth detects it
A code scan flags hand-rolled provider authorize redirects with no state in the flow, and callbacks that exchange the code with no state comparison. SDK-managed flows are not flagged.
OAuth flows run without a state parameter
WHAT WE FOUND
C42 — masked sample
The fix, in three steps
Generate a one-time state before the redirect, send it with the authorize URL, and compare it in the callback before exchanging the code. Three steps.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
What does the state parameter actually protect?
It proves the OAuth round-trip was started by the same browser that finished it. Without it, an attacker can initiate a login as themselves and redirect the victim's browser through the callback — silently linking accounts (login CSRF).
I use Supabase/NextAuth — am I affected?
No — those SDKs generate and verify state (or PKCE) internally. The check only flags hand-rolled redirect/callback code.
What's the fix?
One-time random state in an httpOnly cookie before the redirect, sent with the authorize URL, compared in the callback before the code exchange — mismatch returns 403.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.