Will It Vibe?No CSRF protection for a session app
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
An Express app that sets cookies or uses sessions has no CSRF-token middleware or library, so state-changing form posts can be forged from other origins. Heuristic: SameSite cookies or token headers may already mitigate this.
Why it matters
An app that authenticates with cookies or sessions and has no CSRF defense lets an attacker-controlled page trigger state-changing requests in a logged-in victim, because the browser attaches the session cookie automatically. That can transfer funds, change emails, or delete data without the user acting. This is a heuristic: SameSite cookies or a token-in-header scheme may already mitigate it, so confirm before adding middleware.
How to fix it
Add CSRF protection appropriate to your app: a synchronizer or double-submit token (csrf-csrf, or the csurf successor you prefer) for form-based flows, plus SameSite=Lax or Strict on the session cookie. For token-in-header APIs that never rely on cookies for auth, CSRF may not apply, so document that. Make sure any token is verified on every state-changing method.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo