Will It Vibe?django.views.static.serve wired in with no DEBUG guard
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
django.views.static.serve is registered directly in urlpatterns with no visible enclosing `if settings.DEBUG:` block. Django's own documentation says this view is not hardened for production use; the safe alternative is django.conf.urls.static.static(), which already no-ops when DEBUG is False.
Why it matters
Django's documentation is explicit that django.views.static.serve is not hardened for production use; it exists for local development convenience. Registering it directly in urlpatterns with no DEBUG guard means it runs in every environment, including production, where you generally want a real web server or object storage serving static/media files, not the Django process itself.
How to fix it
Replace the manual serve() registration with django.conf.urls.static.static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT), which already only adds the URL pattern when DEBUG is True and is a no-op otherwise. In production, serve static files via whitenoise or your web server/CDN, and media files from object storage (S3-compatible) or a web-server location block, not through Django.
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