cli-jaw 0.1.6 → 0.1.8

package/skills_ref/security-best-practices/references/python-django-web-server-security.md

@@ -1,882 +0,0 @@
-# Django (Python) Web Security Spec (Django 6.0.x, Python 3.x)
-
-This document is designed as a **security spec** that supports:
-
-1. **Secure-by-default code generation** for new Django code.
-2. **Security review / vulnerability hunting** in existing Django code (passive “notice issues while working” and active “scan the repo and report findings”).
-
-It is intentionally written as a set of **normative requirements** (“MUST/SHOULD/MAY”) plus **audit rules** (what bad patterns look like, how to detect them, and how to fix/mitigate them).
-
----
-
-## 0) Safety, boundaries, and anti-abuse constraints (MUST FOLLOW)
-
-* MUST NOT request, output, log, or commit secrets (API keys, passwords, private keys, session cookies, `SECRET_KEY`, `SECRET_KEY_FALLBACKS`, database passwords).
-* MUST NOT “fix” security by disabling protections (e.g., removing `CsrfViewMiddleware`, sprinkling `@csrf_exempt`, loosening `ALLOWED_HOSTS` to `['*']`, disabling `SecurityMiddleware`, disabling template auto-escaping, disabling permission checks).
-* MUST provide **evidence-based findings** during audits: cite file paths, code snippets, and concrete configuration values that justify the claim.
-* MUST treat uncertainty honestly: if a protection might exist in infrastructure (reverse proxy, WAF, CDN, ingress controller), report it as “not visible in app code; verify at runtime / edge config”.
-* MUST keep fixes compatible with Django’s intended security model: prefer Django’s built-ins (middleware, auth, forms, ORM) over custom security logic whenever possible. Django’s deployment checklist and system checks are part of the intended model. ([Django Project][1])
-
----
-
-## 1) Operating modes
-
-### 1.1 Generation mode (default)
-
-When asked to write new Django code or modify existing code:
-
-* MUST follow every **MUST** requirement in this spec.
-* SHOULD follow every **SHOULD** requirement unless the user explicitly says otherwise.
-* MUST prefer safe-by-default Django APIs and proven libraries over custom security code.
-* MUST avoid introducing new risky sinks (dynamic template rendering from untrusted strings, unsafe redirects, unsafe file serving, shell execution, raw SQL string formatting, SSRF-capable URL fetchers from untrusted input).
-
-### 1.2 Passive review mode (always on while editing)
-
-While working anywhere in a Django repo (even if the user did not ask for a security scan):
-
-* MUST “notice” violations of this spec in touched/nearby code.
-* SHOULD mention issues as they come up, with a brief explanation + safe fix.
-
-### 1.3 Active audit mode (explicit scan request)
-
-When the user asks to “scan”, “audit”, or “hunt for vulns”:
-
-* MUST systematically search the codebase for violations of this spec.
-* MUST output findings in a structured format (see §2.3).
-
-Recommended audit order:
-
-1. Deployment entrypoints (ASGI/WSGI), Dockerfiles, Procfiles, systemd units, platform manifests.
-2. `settings.py` and environment-specific settings modules.
-3. Middleware ordering and enabled protections.
-4. Authn/authz (login, session management, permissions, admin).
-5. CSRF protections and state-changing endpoints.
-6. Templates and XSS.
-7. File handling (uploads/downloads/static/media) and path traversal.
-8. Injection classes (SQL, command execution, unsafe deserialization).
-9. Outbound requests (SSRF).
-10. Redirect handling (open redirects) + CORS + security headers (CSP, HSTS, etc.).
-11. Dependency/pinning and patch posture.
-
----
-
-## 2) Definitions and review guidance
-
-### 2.1 Untrusted input (treat as attacker-controlled unless proven otherwise)
-
-Examples include:
-
-* `request.GET`, `request.POST`, `request.FILES`
-* `request.body`, JSON bodies (e.g., `json.loads(request.body)`), DRF `request.data`
-* URL path parameters (e.g., `<int:id>`, `<slug:...>`)
-* `request.headers` / `request.META` (including `HTTP_HOST`, `HTTP_ORIGIN`, `HTTP_REFERER`, `HTTP_X_FORWARDED_*`)
-* `request.COOKIES`
-* Any data from external systems (webhooks, third-party APIs, message queues)
-* Any persisted content that originated from users (DB rows, cached content, file uploads)
-
-Django explicitly emphasizes “never trust user-controlled data” and recommends using forms/validation. ([Django Project][2])
-
-### 2.2 State-changing request
-
-A request is state-changing if it can create/update/delete data, change auth/session state, trigger side effects (purchase, email send, webhook send), or initiate privileged actions.
-
-### 2.3 Required audit finding format
-
-For each issue found, output:
-
-* Rule ID:
-* Severity: Critical / High / Medium / Low
-* Location: file path + function/class/view name + line(s)
-* Evidence: the exact code/config snippet
-* Impact: what could go wrong, who can exploit it
-* Fix: safe change (prefer minimal diff)
-* Mitigation: defense-in-depth if immediate fix is hard
-* False positive notes: what to verify if uncertain
-
----
-
-## 3) Secure baseline: minimum production configuration (MUST in production)
-
-This is the smallest “production baseline” that prevents common Django misconfigurations. Django provides a “Deployment checklist” and recommends running `manage.py check --deploy` against production settings. ([Django Project][1])
-
-### 3.1 Settings management pattern (SHOULD)
-
-* SHOULD use environment-based configuration (or a secret manager) so production settings are not hard-coded.
-* MUST treat sensitive settings as confidential (e.g., `SECRET_KEY`, DB passwords) and keep them out of source control. Django’s checklist explicitly recommends loading `SECRET_KEY` from env or a file rather than hardcoding. ([Django Project][1])
-* SHOULD separate dev vs prod settings modules, with safe defaults for production (fail closed if critical settings are missing). ([Django Project][1])
-
-### 3.2 Minimum baseline targets (production)
-
-* MUST NOT use `manage.py runserver` as the production entrypoint; use a production-ready WSGI or ASGI server. ([Django Project][1])
-* MUST set `DEBUG = False` in production. ([Django Project][1])
-* MUST set a strong, secret `SECRET_KEY` and keep it secret; MAY use `SECRET_KEY_FALLBACKS` for safe rotation. ([Django Project][1])
-* MUST set `ALLOWED_HOSTS` to expected hosts (no wildcard unless you do your own host validation). ([Django Project][1])
-* MUST enforce HTTPS for authenticated areas (ideally site-wide for any login-capable app) and set `CSRF_COOKIE_SECURE=True` and `SESSION_COOKIE_SECURE=True` when HTTPS is used. ([Django Project][1])
-* SHOULD enable key `SecurityMiddleware` headers/settings: HSTS, Referrer-Policy, COOP, nosniff, SSL redirect (with correct proxy configuration). ([Django Project][3])
-* MUST treat user uploads as untrusted; ensure your web server never interprets them as executable content; keep `MEDIA_ROOT` separate from `STATIC_ROOT`. ([Django Project][1])
-
----
-
-## 4) Rules (generation + audit)
-
-Each rule contains: required practice, insecure patterns, detection hints, and remediation.
-
-### DJANGO-DEPLOY-001: Do not use Django’s development server in production
-
-Severity: High (if production)
-
-Required:
-
-* MUST NOT deploy `manage.py runserver` as the production server.
-* MUST run behind a production-grade WSGI or ASGI server. ([Django Project][1])
-
-Insecure patterns:
-
-* Production docs/scripts using `python manage.py runserver 0.0.0.0:8000`.
-* Docker `CMD`/entrypoint uses `runserver`.
-* Kubernetes/Procfile/systemd units invoking `runserver`.
-
-Detection hints:
-
-* Search for `manage.py runserver`, `runserver 0.0.0.0`, `--insecure`.
-* Check Docker `CMD/ENTRYPOINT`, Procfile, systemd unit files, Helm charts.
-
-Fix:
-
-* Use a production server (WSGI/ASGI) as recommended in Django’s deployment checklist. ([Django Project][1])
-
-Note:
-
-* `runserver` is fine for local development. Only flag if it’s used as the production entrypoint.
-
----
-
-### DJANGO-DEPLOY-002: `DEBUG` MUST be disabled in production
-
-Severity: High
-
-Required:
-
-* MUST set `DEBUG = False` in production.
-* MUST treat any mechanism that exposes debug pages/tracebacks to untrusted users as a critical information disclosure risk. Django’s checklist explicitly warns `DEBUG=True` leaks source excerpts, local variables, settings, and more. ([Django Project][1])
-
-Insecure patterns:
-
-* `DEBUG = True` in production settings.
-* Environment defaults to `DEBUG=True` unless explicitly overridden.
-
-Detection hints:
-
-* Search `DEBUG = True`, `DEBUG=os.environ.get(..., True)`, `DJANGO_DEBUG`, `.env` files.
-* Look for “production” settings modules that import from dev defaults.
-
-Fix:
-
-* Set `DEBUG=False` in prod settings; use explicit environment config.
-* Ensure error reporting is via safe logging/monitoring, not debug pages. ([Django Project][1])
-
----
-
-### DJANGO-CONFIG-001: `SECRET_KEY` must be strong, secret, and rotated safely
-
-Severity: High (Critical if missing in production with signing/sessions)
-
-Required:
-
-* MUST set a large random `SECRET_KEY` in production and keep it secret. ([Django Project][1])
-* MUST NOT commit it to source control or print/log it. ([Django Project][1])
-* SHOULD load it from env or a file/secret store (not hard-coded). ([Django Project][1])
-* MAY rotate keys using `SECRET_KEY_FALLBACKS` to avoid instantly invalidating all signed data; MUST remove old keys from fallbacks in a timely manner. ([Django Project][1])
-
-Insecure patterns:
-
-* Hard-coded `SECRET_KEY = "..."` in repo for production.
-* `SECRET_KEY` reused across environments.
-* `SECRET_KEY_FALLBACKS` contains long-expired keys indefinitely.
-
-Detection hints:
-
-* Search for `SECRET_KEY =`, `SECRET_KEY_FALLBACKS`, `.env` committed files, `print(settings.SECRET_KEY)`.
-
-Fix:
-
-* Load from secret manager / environment variable.
-* If rotating:
-
-  * Set new `SECRET_KEY`
-  * Keep old key(s) temporarily in `SECRET_KEY_FALLBACKS`
-  * Remove old key(s) after the rotation window. ([Django Project][1])
-
----
-
-### DJANGO-HOST-001: Host header must be validated (`ALLOWED_HOSTS` must be strict)
-
-Severity: Medium
-
-Required:
-
-* MUST set `ALLOWED_HOSTS` in production to your expected domains/hosts. ([Django Project][1])
-* MUST NOT set `ALLOWED_HOSTS = ['*']` in production unless you also implement your own robust `Host` validation (Django warns that wildcards require your own validation to avoid CSRF-class attacks). ([Django Project][1])
-* SHOULD configure the fronting web server to reject unknown hosts early (defense-in-depth). ([Django Project][1])
-
-Insecure patterns:
-
-* `ALLOWED_HOSTS = ['*']` (or env expands to `*`) in production.
-* `ALLOWED_HOSTS = []` with `DEBUG=False` (site won’t run, or misconfigured deployments attempt workarounds).
-
-Detection hints:
-
-* Search `ALLOWED_HOSTS`.
-* Check platform environment settings that override `ALLOWED_HOSTS`.
-
-Fix:
-
-* Set `ALLOWED_HOSTS = ['example.com', 'www.example.com', ...]` for prod.
-* Keep dev hosts separate.
-
-Notes:
-
-* Django uses the Host header for URL construction; fake Host values can lead to CSRF, cache poisoning, and poisoned email links (Django security docs call this out). ([Django Project][2])
-
----
-
-### DJANGO-HTTPS-001: If TLS is used cookie transport must be secured
-
-Severity: High (Critical for auth-enabled apps)
-
-NOTE: Only enforce this if TLS is enabled, as it will break non-TLS applications
-
-If using TLS:
-* MUST set:
-
-  * `CSRF_COOKIE_SECURE = True` ([Django Project][1])
-  * `SESSION_COOKIE_SECURE = True` ([Django Project][1])
-* SHOULD consider enabling:
-
-  * `SECURE_SSL_REDIRECT = True` (with correct proxy config) ([Django Project][3])
-  * HSTS via `SECURE_HSTS_SECONDS` (+ includeSubDomains/preload as appropriate). ([Django Project][3])
-
-Insecure patterns:
-
-* Login pages over HTTP, or mixed HTTP/HTTPS with the same session cookie.
-* `CSRF_COOKIE_SECURE=False` or `SESSION_COOKIE_SECURE=False` in production HTTPS.
-* HSTS enabled incorrectly (can break site for the duration).
-
-Detection hints:
-
-* Inspect `settings.py` for `CSRF_COOKIE_SECURE`, `SESSION_COOKIE_SECURE`, `SECURE_SSL_REDIRECT`, `SECURE_HSTS_SECONDS`.
-* Inspect proxy/ingress config for HTTP->HTTPS redirect behavior.
-
-Fix:
-
-* Enable HTTPS redirect and secure cookies.
-* Add HSTS carefully (start with low value, validate, then increase). Django warns misconfig can break your site for the HSTS duration. ([Django Project][3])
-
----
-
-### DJANGO-PROXY-001: Reverse proxy trust must be configured correctly (`SECURE_PROXY_SSL_HEADER`)
-
-Severity: Medium (when behind a TLS proxy)
-
-Required:
-
-* If behind a reverse proxy that terminates TLS, MUST configure Django so `request.is_secure()` reflects the *external* scheme, otherwise CSRF and other logic can break. Django documents using `SECURE_PROXY_SSL_HEADER` for this. ([Django Project][3])
-* MUST only set `SECURE_PROXY_SSL_HEADER` if you control the proxy (or have guarantees) and it strips inbound spoofed headers. Django explicitly warns misconfig can compromise security and lists required conditions. ([Django Project][3])
-
-Insecure patterns:
-
-* `SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")` in an environment where the proxy does not strip user-supplied `X-Forwarded-Proto`.
-* Infinite redirect loops after setting `SECURE_SSL_REDIRECT=True` (often indicates proxy HTTPS detection is wrong). ([Django Project][3])
-
-Detection hints:
-
-* Search `SECURE_PROXY_SSL_HEADER`, `SECURE_SSL_REDIRECT`.
-* Inspect ingress/proxy behavior for stripping forwarded headers.
-
-Fix:
-
-* Set `SECURE_PROXY_SSL_HEADER` only if the proxy strips and sets the header correctly (per Django’s documented prerequisites). ([Django Project][3])
-
----
-
-### DJANGO-SESS-001: Session cookies must use secure attributes in production
-
-Severity: Medium (Only if TLS enabled)
-
-Required (production, HTTPS):
-
-* MUST set `SESSION_COOKIE_SECURE=True` (only transmit over HTTPS). ([Django Project][3])
-* MUST keep `SESSION_COOKIE_HTTPONLY=True` (Django default is `True`). ([Django Project][3])
-* SHOULD keep `SESSION_COOKIE_SAMESITE='Lax'` (Django default is `Lax`) unless a justified cross-site flow requires `None`. ([Django Project][3])
-* SHOULD avoid setting `SESSION_COOKIE_DOMAIN` unless you truly need cross-subdomain cookies (subdomain-wide cookies expand attack surface).
-
-Insecure patterns:
-
-* `SESSION_COOKIE_SECURE=False` in production HTTPS.
-
-IMPORTANT NOTE: Only set `Secure` in production environment when TLS is configured. When running in a local dev environment over HTTP, do not set `Secure` property on cookies. You should do this conditionally based on if the app is running in production mode. You should also include a property like `SESSION_COOKIE_SECURE` which can be used to disable `Secure` cookies when testing over HTTP.
-
-* `SESSION_COOKIE_HTTPONLY=False`.
-* `SESSION_COOKIE_SAMESITE=None` combined with cookie-authenticated state-changing endpoints (higher CSRF risk).
-
-Detection hints:
-
-* Search for `SESSION_COOKIE_` settings, `response.set_cookie(..., httponly=..., secure=..., samesite=...)`.
-
-Fix:
-
-* Set the above explicitly in production settings.
-* Validate compatibility with your auth flows. ([Django Project][3])
-
----
-
-### DJANGO-SESS-002: CSRF cookie settings must be deliberate (HttpOnly has tradeoffs)
-
-Severity: Medium
-
-Required:
-
-* SHOULD set `CSRF_COOKIE_SECURE=True` when using HTTPS/TLS. ([Django Project][3])
-* SHOULD keep `CSRF_COOKIE_SAMESITE='Lax'` unless you have a cross-site requirement. Django default is `Lax`. ([Django Project][3])
-* MAY set `CSRF_COOKIE_HTTPONLY=True` (default is `False`) if your frontend does not need to read the CSRF cookie. If you enable it, your JS must read the CSRF token from the DOM instead (Django documents this). ([Django Project][3])
-
-Insecure patterns:
-
-* `CSRF_COOKIE_SECURE=False` in production HTTPS/TLS.
-* Setting `CSRF_COOKIE_HTTPONLY=True` but still relying on “read csrftoken cookie in JS” patterns (breaks CSRF for AJAX).
-* `CSRF_COOKIE_SAMESITE=None` without a clear reason.
-
-Detection hints:
-
-* Search for `CSRF_COOKIE_` settings.
-* Search JS for `document.cookie` usage to fetch `csrftoken`.
-
-Fix:
-
-* Align cookie settings with your CSRF token acquisition method (cookie vs DOM) as Django describes. ([Django Project][4])
-
----
-
-### DJANGO-CSRF-001: Cookie-authenticated state-changing requests MUST be CSRF-protected
-
-Severity: High
-
-Required:
-
-* MUST keep `django.middleware.csrf.CsrfViewMiddleware` enabled (it is activated by default). ([Django Project][4])
-* MUST include `{% csrf_token %}` in internal POST forms; MUST NOT include it in forms that POST to external URLs (Django warns this leaks the token). ([Django Project][4])
-* MUST protect all state-changing endpoints (POST/PUT/PATCH/DELETE) that rely on cookies for authentication.
-* For AJAX/SPA calls, MUST send the CSRF token via the `X-CSRFToken` header (or configured header name) as documented. ([Django Project][4])
-* MUST be very careful with `@csrf_exempt` and use it only when absolutely necessary; if used, MUST replace CSRF with an appropriate alternative control (e.g., request signing for webhooks). Django explicitly warns about `csrf_exempt`. ([Django Project][2])
-
-Insecure patterns:
-
-* Missing `CsrfViewMiddleware` in `MIDDLEWARE`.
-* `@csrf_exempt` on general-purpose authenticated views.
-* POST/PUT/PATCH/DELETE endpoints with session auth and no CSRF tokens.
-* Using GET for state-changing actions (amplifies CSRF risk).
-
-Detection hints:
-
-* Inspect `settings.py` `MIDDLEWARE` for `CsrfViewMiddleware` and its order (Django notes it should come before middleware that assumes CSRF is handled). ([Django Project][4])
-* Search for `csrf_exempt`, `csrf_protect`, `ensure_csrf_cookie`.
-* Enumerate URL patterns for non-GET methods; confirm CSRF coverage.
-
-Fix:
-
-* Re-enable `CsrfViewMiddleware`, add CSRF tokens to forms, and add AJAX header handling.
-* For caching decorators: if you cache a view that needs CSRF tokens, apply `@csrf_protect` as Django documents to avoid caching a response without CSRF cookie/Vary headers. ([Django Project][4])
-
-Notes:
-
-* When deployed with HTTPS, Django’s CSRF middleware also checks the Referer header for same-origin (Django security docs mention this). ([Django Project][2])
-
----
-
-### DJANGO-XSS-001: Prevent reflected/stored XSS in templates and HTML generation
-
-Severity: High
-
-Required:
-
-* MUST rely on Django template auto-escaping (safe-by-default) for HTML templates. Django security docs highlight that Django templates escape dangerous characters but have limitations. ([Django Project][2])
-* MUST NOT disable auto-escaping broadly (`{% autoescape off %}`) unless the content is trusted or safely sanitized. ([Django Project][5])
-* MUST NOT mark untrusted content as safe:
-
-  * Avoid `mark_safe(...)` on user data.
-  * Avoid `|safe` on user-controlled content.
-* MUST be careful about HTML context pitfalls (e.g., unquoted attributes); Django explicitly shows an example where escaping does not protect an unquoted attribute context. ([Django Project][2])
-* SHOULD prefer safe HTML construction helpers (e.g., `format_html`) rather than manual concatenation that risks missing escapes. ([Django Project][6])
-
-Insecure patterns:
-
-* `{% autoescape off %}{{ user_input }}{% endautoescape %}`
-* `{{ user_input|safe }}`
-* `mark_safe(request.GET["q"])`
-* Unquoted attribute injections: `<style class={{ var }}>...` (Django’s own example). ([Django Project][2])
-
-Detection hints:
-
-* Search templates for `|safe`, `autoescape off`, `safeseq`.
-* Search Python for `mark_safe`, `SafeString`, or direct HTML concatenation with request/DB values.
-* Review any code returning `HttpResponse(user_value)` where `user_value` contains HTML.
-
-Fix:
-
-* Remove unsafe marking; sanitize only when strictly necessary (use an allowlist-based HTML sanitizer).
-* Quote attributes and avoid placing untrusted values into dangerous contexts.
-* Add CSP as defense-in-depth (see DJANGO-CSP-001). ([Django Project][2])
-
----
-
-### DJANGO-TEMPLATE-001: Never render untrusted template source strings
-
-Severity: High to Critical (depends on context and exposure)
-
-Required:
-
-* MUST NOT render templates where the template source string is influenced by untrusted input (request, user content, DB rows editable by untrusted users).
-* MUST treat “template from string” patterns as dangerous, even if Django templates are more constrained than some other engines: they can still leak data from context, bypass escaping, and create XSS or content injection.
-
-Insecure patterns:
-
-* `Template(request.GET["tmpl"]).render(Context(...))`
-* Saving user templates in the DB and rendering them with normal privileges/context.
-
-Detection hints:
-
-* Search for `django.template.Template(`, `Engine.from_string`, `.render(Context(` with non-constant strings.
-* Trace where the template string comes from (admin panels, DB, uploads, requests).
-
-Fix:
-
-* Replace with non-executing formatting (e.g., `string.Template`, explicit placeholders) or a strict allowlisted rendering model.
-* If you *must* support user-defined templates, isolate heavily (separate service/tenant context, strict allowlists, and assume bypasses are possible).
-
----
-
-### DJANGO-SQL-001: Prevent SQL injection (use ORM or parameterized raw SQL)
-
-Severity: High
-
-Required:
-
-* MUST use Django ORM/querysets for normal DB access; Django notes querysets are parameterized and protected from SQL injection under typical use. ([Django Project][2])
-* MUST be very careful with raw SQL; if using `raw()`, `cursor.execute()`, `extra()`, or `RawSQL`, MUST pass parameters separately (e.g., `params=`) and MUST NOT string-interpolate untrusted input into SQL. Django’s raw SQL docs warn to escape user-controlled parameters using `params`. ([Django Project][7])
-* MUST NOT quote placeholders in SQL templates (Django docs explicitly warn that quoting `%s` placeholders makes it unsafe). ([Django Project][8])
-* SHOULD avoid `extra()` and `RawSQL` unless necessary; Django security docs call for caution. ([Django Project][2])
-
-Insecure patterns:
-
-* `cursor.execute(f"SELECT ... WHERE id={request.GET['id']}")`
-* `Model.objects.raw("... %s" % user_input)` (string formatting)
-* `extra(where=[f"headline='{q}'"])`
-* Quoted placeholders: `WHERE othercol = '%s'` (explicitly documented as unsafe). ([Django Project][8])
-
-Detection hints:
-
-* Grep for `.raw(`, `.extra(`, `RawSQL(`, `connection.cursor()`, `.execute(`.
-* Grep for SQL keywords (`SELECT`, `UPDATE`, `DELETE`, `INSERT`) in Python strings.
-* Track untrusted inputs into these call sites.
-
-Fix:
-
-* Prefer ORM queries.
-* If raw SQL is unavoidable, use parameters (`params`, DB-API param binding) and do not quote placeholders. ([Django Project][7])
-
----
-
-### DJANGO-CMD-001: Prevent OS command injection
-
-Severity: Critical to High (depends on exposure)
-
-Required:
-
-* MUST avoid executing system commands with attacker-influenced input.
-* If subprocess is necessary:
-
-  * MUST pass args as a list (not a shell string).
-  * MUST NOT use `shell=True` with attacker-influenced content.
-  * SHOULD use strict allowlists for variable components.
-* SHOULD prefer pure-Python libraries instead of shelling out.
-
-Insecure patterns:
-
-* `os.system(request.GET["cmd"])`
-* `subprocess.run(f"convert {path}", shell=True)` where `path` is user-controlled.
-
-Detection hints:
-
-* Search `os.system`, `subprocess`, `Popen`, `shell=True`.
-* Trace request/DB inputs into those calls.
-
-Fix:
-
-* Replace with library APIs; if unavoidable, hard-code executable and allowlist validated parameters.
-
----
-
-### DJANGO-UPLOAD-001: File uploads must be validated, stored safely, and served safely
-
-Severity: High
-
-Required:
-
-* MUST treat all user uploads as untrusted. Django explicitly warns “Media files are uploaded by your users. They’re untrusted!” ([Django Project][1])
-* MUST ensure the web server never interprets user uploads as executable code (e.g., don’t allow uploaded `.php` or HTML to execute/inline as active content). ([Django Project][1])
-* MUST enforce size limits (at least at the web server; Django security docs recommend limiting upload size at the server to prevent DoS). ([Django Project][2])
-* SHOULD validate file types using allowlists and content checks (not only extensions).
-* SHOULD store uploads outside the application code directory and outside any static root.
-* SHOULD consider serving uploads from a separate top-level/second-level domain to reduce same-origin impact; Django security docs recommend a distinct domain and note that a subdomain may be insufficient for some protections. ([Django Project][2])
-* MUST be aware of polyglot upload risks: Django documents a case where HTML can be uploaded “as an image” by using a valid PNG header (and may be served as HTML depending on the web server). ([Django Project][2])
-
-Insecure patterns:
-
-* Serving uploads inline with `text/html` or without forcing download for potentially active formats.
-* Upload allowlist based only on extension.
-* Upload storage inside static roots or code roots.
-
-Detection hints:
-
-* Search for `request.FILES`, `FileField`, `ImageField`, upload forms/views.
-* Inspect upload serving paths and Nginx/Apache config (media handlers).
-* Check `MEDIA_URL`, `MEDIA_ROOT`, and static config.
-
-Fix:
-
-* Configure the web server to serve uploads as inert bytes (no execution), and consider forcing `Content-Disposition: attachment` for risky types.
-* Use a separate domain for user content when warranted. ([Django Project][2])
-
----
-
-### DJANGO-PATH-001: Prevent path traversal and unsafe file serving (static/media separation)
-
-Severity: High
-
-Required:
-
-* MUST NOT treat user input as a filesystem path for reads/writes/serving.
-* MUST keep `MEDIA_ROOT` and `STATIC_ROOT` distinct; Django settings docs explicitly warn they must have different values to avoid security implications. ([Django Project][3])
-* SHOULD prefer using Django storage APIs keyed by server-side identifiers rather than accepting arbitrary relative paths from users.
-
-Insecure patterns:
-
-* `open(os.path.join(MEDIA_ROOT, request.GET["path"]))`
-* Download endpoints that take `?file=../../...` style parameters.
-* Misconfigured `MEDIA_ROOT == STATIC_ROOT`.
-
-Detection hints:
-
-* Grep for `open(`, `Path(`, `os.path.join(` used with request values.
-* Check `MEDIA_ROOT`, `STATIC_ROOT` in settings. ([Django Project][3])
-
-Fix:
-
-* Use server-side IDs mapped to known files.
-* Keep static and media separated and ensure the web server treats media as untrusted. ([Django Project][3])
-
----
-
-### DJANGO-REDIRECT-001: Prevent open redirects (`next`, `return_to`, `redirect`)
-
-Severity: Medium (High when combined with auth flows)
-
-Required:
-
-* MUST validate redirect targets derived from untrusted input (e.g., `next`, `return_to`).
-* SHOULD restrict to same-site relative paths or allowlisted hosts/schemes.
-* SHOULD use Django’s safe URL helpers (e.g., `django.utils.http.url_has_allowed_host_and_scheme`) rather than custom parsing.
-
-Insecure patterns:
-
-* `return redirect(request.GET.get("next"))` with no validation.
-* Redirect allowlist implemented with naive string checks.
-
-Detection hints:
-
-* Search for `redirect(` and track origin of the target.
-* Search for parameters named `next`, `return_to`, `redirect`, `url`.
-
-Fix:
-
-* Validate with allowlists and default to a safe internal path if validation fails.
-* Ensure host validation via `ALLOWED_HOSTS` remains strict (see DJANGO-HOST-001). ([Django Project][3])
-
----
-
-### DJANGO-HEADERS-001: Enable essential security headers (SecurityMiddleware + clickjacking protection)
-
-Severity: Medium to High
-
-Required:
-
-* SHOULD use `django.middleware.security.SecurityMiddleware` and configure it appropriately (production) for:
-
-  * `X-Content-Type-Options: nosniff` (Django setting `SECURE_CONTENT_TYPE_NOSNIFF`, default `True`). ([Django Project][3])
-  * `Referrer-Policy` (Django setting `SECURE_REFERRER_POLICY`, default `'same-origin'`). ([Django Project][3])
-  * COOP (Django setting `SECURE_CROSS_ORIGIN_OPENER_POLICY`, default `'same-origin'`). ([Django Project][3])
-  * HTTPS redirects and HSTS as appropriate (see DJANGO-HTTPS-001). ([Django Project][3])
-* SHOULD enable clickjacking protection via X-Frame-Options middleware; Django security docs strongly recommend it for sites that don’t need third-party framing. ([Django Project][2])
-
-Insecure patterns:
-
-* Missing SecurityMiddleware.
-* Missing clickjacking protection (or disabling it globally) without a clear framing requirement.
-* Over-broad framing allowances for sensitive endpoints.
-
-Detection hints:
-
-* Inspect `MIDDLEWARE` for SecurityMiddleware and XFrameOptionsMiddleware.
-* Search for per-view disabling of framing/CSRF protections.
-
-Fix:
-
-* Add/enable middleware and configure the settings intentionally. ([Django Project][3])
-
-NOTE:
-
-* Some headers may be set at the edge (CDN/reverse proxy). If not visible in app code, flag as “verify at edge”.
-
----
-
-### DJANGO-CSP-001: Deploy a Content Security Policy (CSP) as defense-in-depth
-
-Severity: Medium (High for apps rendering untrusted content) 
-
-NOTE: It is most important to set the CSP's script-src. All other directives are not as important and can generally be excluded for the ease of development.
-
-Required:
-
-* SHOULD deploy a CSP to mitigate XSS and content injection classes; Django’s security docs recommend CSP and note it is new in Django 6.0. ([Django Project][2])
-* MUST understand CSP limitations:
-
-  * Avoid excluding routes from CSP coverage; Django warns that an unprotected page can undermine protected pages due to same-origin policy. ([Django Project][2])
-* MAY start with `SECURE_CSP_REPORT_ONLY` to iterate safely (Django provides report-only support). ([Django Project][3])
-
-Insecure patterns:
-
-* No CSP on apps that render user-controlled content.
-* CSP excludes “just a couple pages” (weakens overall protection), especially pages with any injection surface. ([Django Project][2])
-* CSP uses overly permissive directives (e.g., widespread `unsafe-inline`) without justification.
-
-Detection hints:
-
-* Search `SECURE_CSP`, `SECURE_CSP_REPORT_ONLY`, and CSP middleware configuration.
-* Inspect reverse proxy/CDN config for CSP headers.
-
-Fix:
-
-* Implement a realistic CSP, ideally report-only first, then enforce. ([Django Project][3])
-
----
-
-### DJANGO-AUTH-001: Password storage must use Django’s secure hashers; password policy must be configured
-
-Severity: High
-
-Required:
-
-* MUST use Django’s built-in password hashing (never store plaintext or reversible encrypted passwords).
-* SHOULD prefer modern hashers and keep defaults updated; Django documents `PASSWORD_HASHERS` and includes modern options (Argon2, bcrypt, scrypt, PBKDF2 variants). ([Django Project][3])
-* SHOULD configure `AUTH_PASSWORD_VALIDATORS` (default is empty) for production password policy. ([Django Project][3])
-
-Insecure patterns:
-
-* Custom password storage or hashing.
-* Plaintext passwords stored in DB fields.
-* No password validation on consumer-facing apps.
-
-Detection hints:
-
-* Search for `.set_password(` usage vs manual hashing.
-* Inspect settings for `PASSWORD_HASHERS` and `AUTH_PASSWORD_VALIDATORS`. ([Django Project][3])
-
-Fix:
-
-* Use Django auth user model APIs.
-* Enable password validators appropriate to the product’s risk profile. ([Django Project][3])
-
----
-
-### DJANGO-AUTHZ-001: Authorization must be explicit and consistent
-
-Severity: High
-
-Required:
-
-* MUST enforce authorization checks on every privileged action (view, modify, admin-like operations).
-* MUST NOT rely on UI-only restrictions (e.g., hiding buttons) without server-side permission checks.
-* SHOULD use Django’s permissions/groups and per-object authorization patterns where applicable.
-
-Insecure patterns:
-
-* Views that assume “user is logged in” implies “user may do action”.
-* Missing authorization checks on update/delete endpoints.
-
-Detection hints:
-
-* Enumerate views that modify state; ensure they validate ownership/permission.
-* Look for use of only `is_authenticated` or only `is_staff` without checking object-level access.
-
-Fix:
-
-* Add explicit permission checks and tests for unauthorized access.
-
----
-
-### DJANGO-ADMIN-001: Django admin must be treated as a high-value target
-
-Severity: High
-
-Required:
-
-* MUST ensure admin is protected by strong authentication and HTTPS-only transport (see DJANGO-HTTPS-001). ([Django Project][1])
-* SHOULD restrict admin exposure (network allowlists, VPN, SSO, or additional authentication controls) when possible.
-* SHOULD audit installed admin extensions and third-party apps for XSS/CSRF exposure.
-
-Insecure patterns:
-
-* Admin exposed to the internet with weak authentication.
-* Admin served over HTTP.
-
-Detection hints:
-
-* Search `urlpatterns` for `admin.site.urls`.
-* Check deployment config for IP allowlisting or auth gateways.
-
-Fix:
-
-* Add network controls and enforce HTTPS.
-
----
-
-### DJANGO-LOG-001: Logging and error reporting must not leak secrets
-
-Severity: Medium to High
-
-Required:
-
-* MUST NOT log secrets (including `SECRET_KEY`, session cookies, auth headers, password reset tokens).
-* MUST configure production logging deliberately; Django’s deployment checklist explicitly calls out reviewing logging before production. ([Django Project][1])
-* MUST ensure `DEBUG=False` in production so exceptions aren’t rendered with sensitive context. ([Django Project][1])
-
-Insecure patterns:
-
-* Logging full request headers or cookies in production.
-* Printing settings dictionaries.
-* Debug error pages.
-
-Detection hints:
-
-* Inspect `LOGGING` config; search for middleware that logs request headers/cookies.
-* Grep for `print(settings` / `logging.info(request.META)` patterns.
-
-Fix:
-
-* Redact sensitive values; log IDs not secrets.
-* Use structured logging and a safe error monitoring tool. ([Django Project][1])
-
----
-
-### DJANGO-SUPPLY-001: Dependency and patch hygiene (Django + security-critical deps)
-
-Severity: Medium (High if known vulnerable versions)
-
-Required:
-
-* SHOULD pin and regularly update Django and security-critical dependencies.
-* MUST respond to Django security releases promptly.
-
-Detection hints:
-
-* Check `requirements.txt`, lockfiles, build images.
-* Identify Django version; compare against latest supported release (Django’s download page publishes current stable and supported branches). ([Django Project][9])
-
-Fix:
-
-* Upgrade to patched versions; add regression tests for previously vulnerable classes.
-
----
-
-## 5) Practical scanning heuristics (how to “hunt”)
-
-When actively scanning, use these high-signal patterns:
-
-* Deployment/dev server:
-
-  * `manage.py runserver`, `runserver 0.0.0.0`, `--insecure` ([Django Project][1])
-* Debug / settings:
-
-  * `DEBUG = True` ([Django Project][1])
-  * `SECRET_KEY =`, `SECRET_KEY_FALLBACKS` ([Django Project][1])
-* Host validation:
-
-  * `ALLOWED_HOSTS = ['*']` ([Django Project][3])
-* HTTPS and proxy:
-
-  * `SECURE_SSL_REDIRECT`, `SECURE_HSTS_SECONDS`, `SECURE_PROXY_SSL_HEADER` ([Django Project][3])
-* Cookies / sessions:
-
-  * `SESSION_COOKIE_SECURE`, `SESSION_COOKIE_HTTPONLY`, `SESSION_COOKIE_SAMESITE` ([Django Project][3])
-  * `CSRF_COOKIE_SECURE`, `CSRF_COOKIE_HTTPONLY`, `CSRF_COOKIE_SAMESITE` ([Django Project][3])
-* CSRF bypasses:
-
-  * `csrf_exempt`, missing `CsrfViewMiddleware`, POST forms without `{% csrf_token %}` ([Django Project][4])
-* XSS:
-
-  * `|safe`, `autoescape off`, `mark_safe(`, HTML string concatenation ([Django Project][5])
-* SQL injection:
-
-  * `.raw(`, `.extra(`, `RawSQL(`, `cursor.execute(` with formatted SQL strings ([Django Project][7])
-* User uploads / media:
-
-  * `request.FILES`, `MEDIA_ROOT`, `MEDIA_URL`, serving media inline; `MEDIA_ROOT == STATIC_ROOT` ([Django Project][1])
-* Redirects:
-
-  * `redirect(request.GET.get("next"))` patterns; missing allowlist validation
-* Security headers and CSP:
-
-  * Missing `SecurityMiddleware`, missing X-Frame-Options protection, missing `SECURE_CSP` adoption (where appropriate) ([Django Project][2])
-
-Always try to confirm:
-
-* data origin (untrusted vs trusted)
-* sink type (template/SQL/subprocess/files/redirect/http)
-* protective controls present (middleware, validation, allowlists, authz checks)
-* whether security headers/controls are set in-app vs at the edge
-
----
-
-## 6) Sources (accessed 2026-01-27)
-
-Primary Django documentation:
-
-```text
-- Django Downloads (current stable & supported branches): https://www.djangoproject.com/download/
-- Django 6.0 Release Notes: https://docs.djangoproject.com/en/6.0/releases/6.0/
-- Django: Deployment checklist (incl. check --deploy, runserver warning, HTTPS/cookies guidance): https://docs.djangoproject.com/en/6.0/howto/deployment/checklist/
-- Django: Settings reference (SecurityMiddleware settings, cookies, SECRET_KEY_FALLBACKS, CSP settings): https://docs.djangoproject.com/en/6.0/ref/settings/
-- Django: Security in Django (XSS/CSRF/SQLi/clickjacking/HTTPS/host header validation/uploads/CSP): https://docs.djangoproject.com/en/6.0/topics/security/
-- Django: CSRF how-to (middleware, csrf_token usage, AJAX header patterns, csrf_exempt cautions): https://docs.djangoproject.com/en/6.0/howto/csrf/
-- Django: Performing raw SQL queries (parameterization guidance): https://docs.djangoproject.com/en/6.0/topics/db/sql/
-- Django: QuerySet API reference (extra() cautions; “do not quote placeholders” guidance): https://docs.djangoproject.com/en/6.0/ref/models/querysets/
-- Django: Template built-ins (autoescape tag): https://docs.djangoproject.com/en/6.0/ref/templates/builtins/
-- Django: Template language reference (turning off autoescape & risks): https://docs.djangoproject.com/en/6.0/ref/templates/language/
-- Django: Utilities reference (e.g., format_html): https://docs.djangoproject.com/en/6.0/ref/utils/
-```
-
-OWASP:
-
-```text
-- OWASP Cheat Sheet Series: Django Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html
-```
-
-[1]: https://docs.djangoproject.com/en/6.0/howto/deployment/checklist/ "https://docs.djangoproject.com/en/6.0/howto/deployment/checklist/"
-[2]: https://docs.djangoproject.com/en/6.0/topics/security/ "Security in Django | Django documentation | Django"
-[3]: https://docs.djangoproject.com/en/6.0/ref/settings/ "Settings | Django documentation | Django"
-[4]: https://docs.djangoproject.com/en/6.0/howto/csrf/ "How to use Django’s CSRF protection | Django documentation | Django"
-[5]: https://docs.djangoproject.com/en/6.0/ref/templates/builtins/ "https://docs.djangoproject.com/en/6.0/ref/templates/builtins/"
-[6]: https://docs.djangoproject.com/en/6.0/ref/utils/ "https://docs.djangoproject.com/en/6.0/ref/utils/"
-[7]: https://docs.djangoproject.com/en/6.0/topics/db/sql/ "https://docs.djangoproject.com/en/6.0/topics/db/sql/"
-[8]: https://docs.djangoproject.com/en/6.0/ref/models/querysets/ "https://docs.djangoproject.com/en/6.0/ref/models/querysets/"
-[9]: https://www.djangoproject.com/download/ "Download Django | Django"