django-securitylisted

# Django Security ## When to use This skill is the Django-specific layer on top of `secure-coding`. Use it when Django gets in its own way: defaults that invite misunderstanding, ORM paths that look safe but still allow SQLi, or settings that may go wrong per environment. Triggers on: - A question like "review this Django app", "is our deploy safe", "what are our SECURE_ settings", "are we using CSRF correctly", "Django admin hardening". - Presence of `manage.py`, `settings.py`, `urls.py`, `models.py`, `views.py`, Django middleware class paths in `MIDDLEWARE`, DRF `viewsets.py` or `serializers.py`. - A PR that introduces `@csrf_exempt`, `|safe`, `mark_safe`, `.raw()`, `.extra()`, `RawSQL`, or `HttpResponse(user_input)`. - Django version bumps that are a security release (release notes will explicitly mention fixes). - A handoff from `security-review` where Django is in the stack. ### When NOT (handoff) - General Python secure-coding (not Django-specific) → `secure-coding`. - DRF as an API layer overlaps heavily with `api-security`: OAuth/JWT flow, OWASP API Top 10 belong there. Django-specific DRF foot-guns (e.g. `HyperlinkedModelSerializer` authorization bypass) stay here. - SAST tool config (Bandit, Semgrep `p/django`) → `sast-orchestrator`. - Dep vulns in Django or third-party packages → `cve-triage`. - Deploy infrastructure (nginx, gunicorn, containers) → `container-hardening` / `iac-security`. - Secrets handling (SECRET_KEY, DB creds) → `secrets-scanner`. ## Appro