The defaults do a lot
Django protects against injection through the ORM, escapes template output by default, includes cross-site request forgery protection and provides sensible password hashing.
Most Django vulnerabilities are in code that worked around the defaults: raw SQL with string formatting, marked-safe template output, or exempted CSRF views.
What still needs your attention
- Authorisation — record-level access, which Django does not provide
- File uploads — where they are stored and how they are served
- Dependencies — audited automatically on every build
- Production settings — debug, hosts, cookies, HTTPS
- Secrets — out of the repository, rotated
Where the defaults get bypassed
| Bypass | Risk |
|---|---|
| Raw SQL with string formatting | Injection |
| Marking user content as safe | Cross-site scripting |
| CSRF exemption on a view | Request forgery |
| Serving media from the code directory | Code execution |
| Disabling checks to make something work | Whatever they protected against |
Each of those has a legitimate use and each should be an explicit, reviewed decision rather than a convenience.
Run the built-in check
Django includes a deployment check that reports on production configuration. Running it before launch catches the common misconfigurations in seconds.
It should be part of the deployment pipeline rather than something someone remembers to run.
Test authorisation adversarially
- Two accounts trying to reach each other's records
- Direct URL access with another user's identifiers
- Exports and API endpoints, not just screens
- Admin access, which is powerful and frequently over-granted