@khalidsaidi/skillrunner 0.1.2 → 0.1.3

package/dist/registry/skills/openai-security-best-practices/upstream/references/python-django-web-server-security.md

@@ -0,0 +1,882 @@
+# 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"