Django Penetration Test Preparation Checklist

Problem statement

A customer, auditor, or investor requires a penetration test of your Django application. Tests are expensive and time-boxed; if testers spend the first days reporting missing headers, verbose errors, and outdated packages, they have less time for the business logic flaws that matter. Good preparation removes the easy findings, gives testers what they need to go deep, and makes sure the results lead to fixes.

1. Run python manage.py check --deploy, a header scanner, and dependency audits, and fix what they report.
2. Agree scope in writing: domains, APIs, mobile apps, admin, roles, out-of-scope systems, and testing windows.
3. Provide a production-like environment with seeded test accounts for each role and realistic data.
4. Keep logging, alerting, and WAF behavior realistic, and tell your hosting provider if required.
5. Plan remediation: owners, severity-based deadlines, and a retest window.

Checklist

Fix the routine findings first

• DEBUG = False everywhere testers can reach; custom 404 and 500 pages without stack traces.
• check --deploy clean: secure cookies, HSTS, SSL redirect, X-Frame-Options, SECURE_CONTENT_TYPE_NOSNIFF.
• Content Security Policy, Referrer-Policy, and Permissions-Policy headers set.
• Dependencies current: pip-audit and npm audit clean or with documented exceptions; Django on a supported release.
• Admin at a non-obvious path or behind SSO/VPN, with 2FA and brute-force protection.

Scope and rules of engagement

• In-scope hosts, APIs, and apps listed; third-party services (payment, email) explicitly out of scope.
• Test types agreed: authenticated and unauthenticated web testing, API testing, business logic, infrastructure.
• Rules: no denial of service, no social engineering unless agreed, data handling and deletion rules.
• Contacts on both sides, emergency stop procedure, and testing windows.
• Cloud provider policies checked (most allow testing your own resources without approval, with restrictions).

Test environment and access

• Staging environment matching production configuration, or production with agreed safeguards.
• Test accounts for every role (customer, staff, admin, API client), plus a second tenant for multi-tenant isolation tests.
• Realistic but non-sensitive seed data; no real personal data in test environments.
• API documentation (OpenAPI schema), and mobile app builds if in scope.
• Testers' IP addresses noted so alerts can be correlated, without whitelisting them past the WAF unless agreed.

Monitoring during the test

• Logging and alerting left on to see whether attacks are detected; this is free detection testing.
• On-call informed of the testing window.
• Backups taken before testing, especially on staging with destructive tests in scope.

Remediation and retest

• Findings tracked as issues with owners and deadlines by severity (for example critical in days, high in weeks).
• Root causes fixed broadly (for example, adding permission checks to all views, not just the reported one).
• Retest scheduled; final report and remediation evidence stored for customers and auditors.

Explanation

Penetration testers use automated scanners first, which surface configuration issues Django can fix with a few settings. Those findings are real but cheap; leaving them in place uses up paid testing time and fills the report. With the basics fixed and good access provided, testers can examine authorization logic, multi-tenant isolation, workflows, and APIs, where costly vulnerabilities usually live. Treating remediation and retesting as part of the engagement turns the report into actual risk reduction.

Edge cases / notes

• Production testing. If production is in scope, agree on rate limits, avoid destructive tests, and schedule low-traffic windows.
• Bug bounty vs pentest. A bounty gives continuous coverage; a pentest gives a defined, documented assessment. They complement each other.
• Compliance reports. SOC 2, ISO 27001, and customers may need the report and remediation proof.

Next steps

• Close header gaps with the Django Security Headers Checklist.
• Protect the admin with the Django Admin Security Checklist.
• Publish how to report issues with Add security.txt and a Disclosure Process.

FAQ

What do pentests usually find in Django apps?

Missing headers, verbose errors, outdated dependencies, weak rate limits, and most seriously, broken object-level authorization (IDOR).

Should testing happen in staging or production?

Staging that mirrors production is common. Production testing needs agreed safeguards.

Should testers be whitelisted past the WAF?

It depends on goals. Whitelisting tests the app itself; not whitelisting tests your defenses as deployed.

What happens after the report?

Fix findings by severity, address root causes, retest, and keep the evidence.