Will It Vibe?HTTP verb does not match the route name
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A route is registered with .get(...) but its path reads as a mutating action (for example /deleteUser, /updateOrder, /removeItem). GET requests are supposed to be safe and idempotent: browsers, crawlers, proxies, and link-prefetch can all trigger a GET with no confirmation and no CSRF token, so a state change behind one is a real risk as well as a REST-semantics bug.
Why it matters
A GET route is supposed to be safe: reading it should never change server state. When a route named /deleteUser or /updateOrder is wired to .get(...), a browser can trigger it with nothing more than a link, an <img> tag, a bookmark, or automatic link-prefetching, none of which carry a CSRF token or ask for confirmation. Search engine crawlers and corporate link-scanning proxies that follow GET links can trigger it too, sometimes deleting data no human ever intended to touch.
How to fix it
Change the route to a method that matches what it does: POST for creation, PUT or PATCH for updates, DELETE for removal. Update the client code that calls it to use the new method and, if the app has session-based auth, make sure CSRF protection covers the corrected route the same way it covers your other mutating endpoints.
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