Free Django Security Scanner
Scan your Django application for the most common production mistakes: DEBUG=True leaking secrets, missing SECURE_* middleware, exposed /admin, and outdated Django versions with known CVEs.
Scan My Django App — FreeNo signup · No credit card · Results in 30 seconds
What the scanner checks
DEBUG=True in production
Detects Django running with DEBUG enabled, which exposes environment variables, SQL queries, and full stack traces on any error page.
Exposed /admin panel
Tests if Django Admin is accessible at the default /admin URL without rate limiting or IP restrictions — a frequent brute-force target.
ALLOWED_HOSTS misconfiguration
Detects ALLOWED_HOSTS=['*'] by testing Host header spoofing, which enables cache poisoning and password reset hijacking.
SECURE_* settings
Verifies SECURE_SSL_REDIRECT, SECURE_HSTS_SECONDS, SESSION_COOKIE_SECURE, and CSRF_COOKIE_SECURE are enforced via HTTP response behavior.
CSRF protection
Tests CSRF middleware enforcement on POST/PUT/DELETE endpoints and verifies csrftoken cookie has Secure and SameSite flags.
Django version and CVEs
Identifies the Django version from response headers and maps it against known Django security advisories.
Django Is Secure by Default — Until It's Not
Django ships with strong security defaults: CSRF middleware, SQL injection protection via the ORM, XSS auto-escaping in templates, and clickjacking protection. The problem is that deploying Django requires flipping several non-default settings — DEBUG, ALLOWED_HOSTS, SECURE_SSL_REDIRECT, SECURE_HSTS_SECONDS — and forgetting any one of them creates a real vulnerability.
The number-one Django breach pattern is DEBUG=True in production. Django's debug error page shows environment variables, database credentials, and the full settings module. Combine that with ALLOWED_HOSTS=['*'] and you have a Host-header-injection attack surface that breaks password reset links and enables cache poisoning. Our scanner tests for these configuration issues from the outside.
Frequently Asked Questions
How do I check if DEBUG is False in production?
Trigger a 404 error by visiting a random URL. If Django returns its debug error page with technical details, DEBUG=True. If it returns a minimal 404 or your custom error template, DEBUG=False. Always set DEBUG=False and define ALLOWED_HOSTS explicitly.
What should ALLOWED_HOSTS be set to?
List every domain that serves your Django app — never use ['*'] in production. For example: ALLOWED_HOSTS = ['example.com', 'www.example.com']. This prevents Host header injection attacks that exploit password reset tokens and email links.
Which SECURE_* settings do I need?
At minimum: SECURE_SSL_REDIRECT=True, SECURE_HSTS_SECONDS=31536000, SECURE_HSTS_INCLUDE_SUBDOMAINS=True, SESSION_COOKIE_SECURE=True, CSRF_COOKIE_SECURE=True, and SECURE_CONTENT_TYPE_NOSNIFF=True. Run 'python manage.py check --deploy' to audit.
Is Django Admin safe to expose at /admin?
It's safer than most frameworks, but still a brute-force target. Change the URL from /admin to something non-obvious, enforce strong passwords, enable django-otp for 2FA, rate limit login attempts, and consider IP-restricting the admin URL in your webserver config.
Does Django prevent SQL injection automatically?
Yes, when you use the ORM (Model.objects.filter(), get(), etc.) — all queries are parameterized. The risk is when you use raw() or execute() with string formatting instead of query parameters. Always pass user input as parameters, never concatenate into SQL strings.
Deploy Django without the gotchas
Free, instant, no signup. Detailed vulnerability report with fix instructions.
Run Free Django Scan