Will It Vibe?Sensitive view with no auth guard decorator
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
A function-based view whose name suggests a sensitive action (delete, admin, approve, ban, refund, ...) has no @login_required, @permission_required, @staff_member_required, or @user_passes_test decorator directly above it. Heuristic: authentication applied via a class-based view mixin, router-level dependency, or global middleware would not show up here, so confirm before assuming the route is unprotected.
Why it matters
A view whose name suggests a sensitive action (deleting, approving, banning, refunding, administering something) has no @login_required, @permission_required, @staff_member_required, or @user_passes_test decorator directly above it. Without one of those, anyone who can reach the URL, authenticated or not, can trigger the action, which is a broken access control gap on exactly the endpoints where it matters most.
How to fix it
Add the appropriate guard decorator: @login_required for anything that just needs an authenticated user, @permission_required("app.some_permission") or @staff_member_required for admin-only actions, or @user_passes_test(...) for a custom rule. Check whether the same protection is already applied at the URL level via a class-based view mixin or a decorator on an entire urlpatterns include before assuming the view is unguarded, since this check only sees decorators on the function itself.
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