01 - Admin
Admin Panel Exposure (/admin/)
Django's admin interface is a powerful tool that provides direct database access, user management and model manipulation. When accessible at the default /admin/ path without additional protection, it becomes a high-value target for brute force attacks, credential stuffing and privilege escalation. Automated scanners check /admin/ on every Django site they encounter. We test admin panel accessibility, authentication strength, URL predictability and whether additional protections like IP restrictions or multi-factor authentication are in place.
02 - Debug
DEBUG=True in Production
Django's debug mode generates detailed error pages that expose your settings module, installed applications, middleware stack, template directories, database configuration and full Python tracebacks. When DEBUG=True reaches production, any unhandled exception hands attackers a blueprint of your application architecture. This includes secret keys, database credentials and internal paths. We trigger error conditions across your application to verify debug mode is disabled and that custom error handlers do not leak sensitive information.
03 - CSRF
CSRF Middleware Bypass
Django's CsrfViewMiddleware protects against cross-site request forgery by default, but developers routinely disable it with @csrf_exempt decorators on API views, webhook endpoints and AJAX handlers. When CSRF protection is removed from state-changing views, attackers can forge requests from malicious sites that execute actions with the victim's authenticated session. We identify all views with CSRF exemptions, test them for forgeability and verify that alternative protections like token-based authentication are properly implemented.
04 - ORM
ORM Injection Through Raw Queries
Django's ORM prevents SQL injection when used correctly, but developers frequently bypass it with raw(), extra(), RawSQL() and cursor.execute() for complex queries. User input concatenated into these raw SQL expressions creates injection vulnerabilities that the ORM's parameter binding cannot prevent. We trace user input from request parameters through views, serializers and model managers to identify raw query usage that accepts unsanitized data, including through Django REST Framework filters and search backends.
05 - Template
Template Injection
Django's template engine auto-escapes HTML by default, but server-side template injection occurs when user input is used to construct template strings dynamically. If an attacker can control part of a template string passed to Template() or render_to_string(), they can execute arbitrary Python code on the server. The |safe filter and mark_safe() also disable auto-escaping, reintroducing XSS when applied to user-controlled data. We test for both server-side template injection and XSS through unsafe template usage.
06 - Secret
SECRET_KEY Exposure
Django's SECRET_KEY is used for cryptographic signing including session tokens, CSRF tokens, password reset links and signed cookies. If the SECRET_KEY is exposed through version control, DEBUG error pages, backup files or environment variable leaks, attackers can forge sessions, bypass CSRF protection, generate valid password reset links and impersonate any user. We check for SECRET_KEY exposure through multiple vectors and verify that key rotation procedures are in place.
07 - Framing
Clickjacking via Missing X-Frame-Options
Django includes XFrameOptionsMiddleware that sets X-Frame-Options to DENY by default, preventing your pages from being embedded in iframes on malicious sites. However, developers disable this middleware or use @xframe_options_exempt decorators to allow legitimate embedding, inadvertently enabling clickjacking attacks on sensitive pages. We test for missing or misconfigured framing protections, identify exempt views and verify that Content-Security-Policy frame-ancestors directives provide additional protection.
08 - Files
Insecure File Serving
Django's development server serves static and media files directly, but this functionality should never reach production. When MEDIA_ROOT or STATIC_ROOT are served without proper access controls, uploaded files become publicly accessible regardless of intended permissions. Uploaded Python files, configuration backups and user-submitted content may be served directly by the web server. We test file upload handling, media file access controls, path traversal in upload paths and whether Django's development file serving is exposed in production.
