Will It Vibe?[AllowAnonymous] on a sensitive-looking controller action
Part of Security, which counts for 30% 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
[AllowAnonymous] sits on an action or inside a controller whose name suggests admin/delete/internal/purge/secret functionality, removing authentication for what looks like a sensitive endpoint. This is a naming heuristic: it can false-positive on genuinely public admin-login or health-check actions, so treat it as a prompt to double-check, not a confirmed bug.
Why it matters
An [AllowAnonymous] attribute on an action or inside a controller whose name reads as admin, delete, internal, purge, or secret removes authentication from what is very likely meant to be a protected operation. If this was left over from debugging or copied from a scaffold, the endpoint is reachable by anyone who finds its route, with no login required.
How to fix it
Confirm whether the action genuinely needs to be public. If it does not, remove [AllowAnonymous] and rely on the controller/action's normal [Authorize] policy; if it does (for example, a public status page inside an otherwise-admin area), add a comment explaining why and consider moving it to a clearly-named, separate controller so the exception is obvious on review.
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