Begin with assets, actors and trust boundaries
Threat modeling is more useful than assembling random security headers. Identify protected assets such as customer identity, login sessions, payment confirmation, private documents and privileged actions. Map entry points including browser forms, REST endpoints, webhooks, uploads, background jobs and admin consoles. Distinguish the authenticated actor from data supplied by that actor: even a logged-in user can submit a malicious object identifier. For every boundary, ask what can be forged, replayed, injected, exfiltrated or exhausted. Record controls and verification tests beside each threat.
Authentication is not authorization
A valid session establishes a principal but does not grant universal access. Every operation must verify permission to the specific record and field at the server. A product owner should not be able to view another seller's private orders by substituting an identifier in the URL. A user who can update their profile should not be able to set is_staff or payment_verified. Design policy checks around role, ownership, tenant and record state; test negative cases with two different user accounts. Client-side hiding of a button has no security value on its own.
Cross-site requests, tokens and cookies
CSRF attacks exploit a browser's tendency to attach credentials to requests initiated by another site. Django's CSRF middleware mitigates many such attacks for protected requests, but developers must keep it enabled and understand trusted-origin rules. Cookies for production sessions should use Secure and a suitable SameSite policy, with HttpOnly where appropriate. Cross-origin API integrations require separate authentication design and careful CORS configuration; permissive CORS is not a substitute for CSRF defenses. Never mark an entire payment endpoint csrf_exempt merely to suppress an error without implementing a proper signature and replay defense.
Build a defensible Content Security Policy
A Content Security Policy can limit script execution and resource loading when configured correctly. Inventory required origins for scripts, styles, images, frames and outbound connections. Prefer a nonce or hash-based policy to broad unsafe-inline allowances; test gradually with report-only mode and observe violations before enforcing. Do not blindly paste restrictive directives into a production site that depends on existing scripts. Establish at least restrictive object loading and trusted base URI settings where compatible with the application, and document any exceptions. CSP complements input validation and output encoding rather than replacing them.
File uploads and server-side request risks
Treat uploads as hostile input: enforce size limits, inspect actual content, avoid execution in storage paths and use generated storage names. Do not trust client-provided filename, extension or MIME type alone. When the server fetches remote URLs, prevent server-side request forgery by restricting destinations, resolving DNS safely and blocking access to private networks and cloud metadata endpoints. Follow redirects cautiously, and avoid sending internal authorization headers to untrusted hosts. An image processing service needs time, memory and dimension limits to prevent resource exhaustion.
Passwords, MFA, logging and incident response
Use vetted password hashing and authentication systems, rate-limit sensitive operations and provide stronger factors for privileged accounts. Log security-relevant events such as role changes, repeated access denials and webhook signature failures without recording passwords, secret keys or payment tokens. Protect logs from tampering and establish retention policy. A security playbook should specify how to revoke sessions, rotate credentials, restore backup and preserve evidence after an incident. Validation includes not only prevention but the ability to identify and recover from an actual failure.
Verify controls with standards and abuse tests
Build an abuse-case matrix for every high-risk route: anonymous requests, unauthorized user, wrong tenant, invalid object state, duplicate request, malformed token and excessive rate. Include SAST and dependency checks as supporting signals, not substitutes for active authorization testing. OWASP ASVS version 5.0 provides a structured requirements catalogue for threat-driven assessment; choose applicable controls and document exceptions. Security is not proven by a single successful login or an error-free homepage. References: https://owasp.org/www-project-application-security-verification-standard/ and https://docs.djangoproject.com/en/5.2/topics/security/ .
Editorial disclosure: Original advanced educational content by Mojtaba Roozegar. Examples are illustrative, not an audit of a particular production deployment or a guarantee of outcomes. Relevant external technical references are linked within each article.