Django Security Scanner: DEBUG & CSRF Testing

Django Security Scanner

Scan your Django application for the most common production mistakes: DEBUG=True leaking secrets, missing SECURE_* middleware, exposed /admin, and weak cookie and header settings.

Scan My Django App. Free

No signup · No credit card · Scan runs in 60 seconds, verify your email to view results

Rather not remember to rescan? We can scan your site every month and email you the results. See pricing

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.

Django name in error pages

Requests a URL that cannot exist and reads the 404 page. Django's debug 404 lists your URL patterns and names the framework. The scan flags the framework name, stack traces and file paths in any error page.

SECURE_* settings

Reads the response for the effects of your SECURE_* settings: cookie flags, HSTS, nosniff, X-Frame-Options and Referrer-Policy. It cannot read settings.py, only what those settings put on the wire.

CSRF token on login forms

Finds login forms at common paths, including /admin/login, and checks for the csrfmiddlewaretoken field. Any csrftoken cookie the page sets is checked for Secure, HttpOnly and SameSite like every other cookie.

HTTPS redirect and HSTS

Requests the http:// version of your site and follows the redirect chain, then checks the final response for Strict-Transport-Security. These are what SECURE_SSL_REDIRECT and SECURE_HSTS_SECONDS produce.

Django Is Secure by Default. Until It's Not

Django security is the gap between Django's strong defaults and the configuration that developers actually ship to production. The framework gives you CSRF protection, ORM-based SQL injection prevention, and XSS auto-escaping out of the box. What trips people up is the deployment checklist: DEBUG needs to be False, ALLOWED_HOSTS needs specific domains, and five SECURE_* settings need to be enabled. Django even warns about each one in its own documentation-but it's easy to miss when you're moving fast.

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 checks the DEBUG half from the outside; ALLOWED_HOSTS is one you have to check yourself.

Laptop screen showing colorful Python code, representing a Django project — Photo by Mohammad Rahmani on Unsplash

One request, read the way the scanner reads it

The scan asks your site for /this-path-does-not-exist-8f4a2b7c. Nothing should live there, so whatever comes back is your 404 handling, and in Django that page says a lot about how you deployed.

With DEBUG = True you get the yellow page: "Page not found (404)", a line saying Django tried these URL patterns in your URLconf, and then the patterns themselves. Every route you have defined, admin URLs included, in order. The footer even says "You're seeing this error because you have DEBUG = True in your Django settings file." The scanner reports that as Django framework name in the 404 result, because the page names Django. If the 500 probe returns a traceback with paths like /app/... or /home/deploy/..., it adds a stack-trace and a file-path finding on top.

With DEBUG = False you get your own 404.html, or Django's plain "Not Found". No framework name, no patterns, nothing to report.

That is why one URL tells more than most of the other checks put together. A site that leaks its URL map on a 404 also tends to have the rest of the production checklist undone, so read the other results with that in mind.

The rest of what the scan sees maps back to settings.py like this:

You set in settings.py	The scan sees
`DEBUG = False`	No framework name, stack trace or path in the 404/500 probes
`SESSION_COOKIE_SECURE = True`, `CSRF_COOKIE_SECURE = True`	`Secure` on the `sessionid` and `csrftoken` cookies
`SECURE_SSL_REDIRECT = True`	`http://` redirects to `https://`
`SECURE_HSTS_SECONDS = 31536000`	`Strict-Transport-Security` on the response
`SECURE_CONTENT_TYPE_NOSNIFF = True` (default)	`X-Content-Type-Options: nosniff`
`X_FRAME_OPTIONS = "DENY"` (default)	`X-Frame-Options: DENY`
`SECURE_REFERRER_POLICY` (default `same-origin`)	`Referrer-Policy`

One warning you can usually ignore: if csrftoken shows up as missing HttpOnly, that is Django's default (CSRF_COOKIE_HTTPONLY = False), because JavaScript has to read the token for AJAX posts. The scan flags it anyway, since it can't know whether your front end needs it.

Two things only you can check, because they never show up in a response: ALLOWED_HOSTS and SECRET_KEY. Run python manage.py check --deploy on the production settings; Django's own deployment checklist explains each warning it prints. Then run this scan against the deployed URL to confirm the settings survived the trip through your proxy and CDN. The two disagree more often than you'd expect, usually because a proxy strips or overrides a header.

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.

Why does the scan show no cookies on my Django site?

Django only sets sessionid after a login and csrftoken when a page renders a form with {% csrf_token %}. The scan requests your homepage without logging in, so a homepage with no form often sets no cookies at all. That is normal. It just means the cookie check had nothing to inspect.

Can the scanner tell which Django version I run?

Usually not, and that is a good sign. Django does not send its version in headers. If a version appears in your results, something else is leaking it, typically a debug page or a Server header from the app server.