secure-code-auditor / rules

---
description: Backend security review and secure-by-default coding for Django and DRF, on an OWASP Top 10:2025, API Security Top 10:2023, and ASVS 5.0 foundation. Apply when backend code is written or reviewed and touches authentication, sessions, cookies, JWT, OAuth2/OIDC, API keys, password hashing, permissions, access control, IDOR, SSRF, path traversal, open redirect, impersonation, SQL/command/template injection, LDAP, row-level security, encrypted columns, NoSQL, Redis, file uploads, S3, serializers, rate limiting, CSRF/CORS, OpenAPI schema, GraphQL, Django Ninja, gRPC, AI agents, MCP tools, secrets, payments, webhooks, Celery, Django tasks, race conditions, ReDoS, caching, deserialization, async/ASGI, WebSockets, audit logging, erasure, retention, personal data, migrations, JWKS, mutual TLS, SECRET_KEY, SBOM, X-Forwarded-For, SPF/DKIM/DMARC, or deployment config, even if "security" is never used. Canonical instructions live in SKILL.md and references/.
alwaysApply: false
---

When you review backend security or write backend code in this repository,
use the skill in `SKILL.md` as the source of truth. Read `SKILL.md` first
for the router, the ownership table, and the mode logic. Then open the
relevant `references/*.md` file(s).

During a task, change no file of this skill unless the task is a change to this
skill. After the task, if this skill gave wrong or incomplete information, load
`SELF-IMPROVEMENT.md` and obey it. Before the task, if
`~/.skill-improvements/secure-code-auditor/` exists, do section 3 of that file.

The router is grouped: the OWASP Top 10:2025 spine, then cross-cutting
surfaces, then package decisions. Pick the group, then the row. Where two
rows could both match, the "Ownership and boundaries" table below the router
names the one file that owns the topic. Read that table before you assume a
topic is duplicated.

At review-time, read `references/01-audit-workflow.md` before any topic file.
It owns the sweep. That sweep is the phase order and per-phase artifacts,
the entry-point inventory enumerated from declarations, and principals and
boundaries. It is also the hypothesis order, the budget rule for a large
tree, and the six-item verification gate with the benign-pattern catalog.
The coverage ledger and the WSTG section mapping complete it. The topic
files answer the questions that sweep raises. Review-time produces
prioritized findings. Each carries a severity, a location, a CWE and
OWASP mapping, the confirmed source-to-sink path with the protection that
failed, and a fix. The codebase stays read-only, and the report ends with
what was not reviewed.

At write-time, apply the secure-default contract while you generate code, and
close with a short security-decisions note rather than a findings report.
Each write-time rule sits beside the control it completes, so the file you
opened for the concern already carries the rule for writing it. Where a
secure default conflicts with the request, apply the default and say so in
one line. `references/00-methodology-and-severity.md` holds the methodology,
both output formats, the severity rubric and its baseline table, the ASVS
chapter mapping, and the conflict rule.

Read-only triage scripts sit under `scripts/`. All three parse with the `ast`
module rather than match lines. A hit is therefore a structural match, and it
names the reference file that owns it. `entrypoint_inventory.py` enumerates
the declared entry points a sweep starts from. `settings_scan.py` reads a whole
settings package rather than a single module. `dangerous_patterns.py` reports
risky-pattern indicators, and `--selftest` proves the scanner itself. Do not
rely on this summary alone — read the referenced files.