Secure code auditor
Backend security Agent Skill that helps AI audit code, detect vulnerabilities, and generate secure-by-default backend applications, with deep Django/DRF coverage and guidance for any backend stack.
npx -y skills add n-shadloo/secure-code-auditorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Backend security auditor with deep Django and Django REST Framework coverage layered on a general OWASP Top 10 (2025) and API Security Top 10 (2023) foundation. Use whenever backend code is being written or reviewed and security is in scope — including any time the work touches authentication, login, sessions, JWT, OAuth2/OIDC, social login, API keys or tokens, permissions or access control, user-supplied input, the ORM or raw SQL, file uploads, serializers or API endpoints, secrets or settings, payments, email or notifications, background tasks, caching, async/ASGI or WebSockets, signals or lifecycle hooks, migrations, or deployment configuration, even if the word "security" is never used. Runs in two modes: review-time (audit existing code and return prioritized, actionable findings with severity, location, and a concrete fix) and write-time (apply secure defaults and flag risky patterns while generating code). Django/DRF is the primary target; the general layer makes it useful for any backend stack.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
7.6 KB, as published. Nobody here has run it
secure-code-auditor
A backend security skill. It reviews and hardens server-side code, with
Django/DRF as the deep specialty and a general OWASP layer that applies to any
stack. Scope is the backend: server-side code, data handling, configuration,
and the deployment/runtime the backend owns. It does not cover browser/frontend
concerns except where the server controls output (encoding, headers, cookies).
Its canonical content is reused by other agents (Codex, Cursor, Gemini CLI) via
AGENTS.md, with Claude as the primary integration.
How the reference material is organized
Everything is arranged on the OWASP Top 10:2025 spine. Category files and cross-cutting topic references have two layers:
- Principle — the vulnerability, why it matters, and the defense, stated stack-agnostically so it's useful in any backend language.
- Django & DRF implementation — the specific settings, code patterns, correct/incorrect examples, gotchas, and hardening steps. This is where the depth lives.
Load only the file(s) relevant to the concern in front of you.
| Concern | Reference file |
|---|---|
| Method & severity model, report format, mode selection | references/00-methodology-and-severity.md |
| Access control, IDOR/BOLA, object- & function-level authz, cache-mediated data leaks, SSRF, open redirect, multi-tenancy, admin access | references/a01-broken-access-control.md |
DEBUG/ALLOWED_HOSTS, SECURE_/SESSION_/CSRF_* matrix, CORS, headers, check --deploy | references/a02-security-misconfiguration.md |
Dependencies, third-party vetting/maintained-package gate, pinning/hashing, pip-audit, EOL frameworks, migrations/data integrity, SBOM | references/a03-software-supply-chain.md |
| Password hashing, TLS-in-transit, data at rest, signing, reset tokens, secrets | references/a04-cryptographic-failures.md |
| SQL/ORM injection, command injection, template injection, header/email injection, server-side output | references/a05-injection.md |
| Rate limiting/anti-automation, business-logic and email/notification abuse, missing limits, insecure defaults | references/a06-insecure-design.md |
| Sessions, JWT/SimpleJWT, OAuth2/OIDC/social login, API keys, brute force, MFA, password reset, allauth/dj-rest-auth/OAuth Toolkit, enumeration | references/a07-authentication-failures.md |
| Insecure deserialization (pickle/yaml), Celery serializer, signed data, CI/CD integrity | references/a08-integrity-and-deserialization.md |
| Sensitive-data leakage in logs, audit logging, lifecycle hooks/signals, alerting, log injection | references/a09-logging-and-alerting.md |
| DEBUG/error views, stack-trace leakage, fail-open checks, race conditions/TOCTOU | references/a10-exceptional-conditions.md |
| Serializer over-exposure/mass assignment, pagination/filter leakage, throttling, default auth/permission classes, DRF+CSRF | references/api-drf-specific.md |
| Async/ASGI boundaries, sync ORM access, task/request context, WebSocket/Channels origin, authentication, authorization, and limits | references/async-and-channels.md |
| File uploads, type/content validation, safe names/storage/serving, SVG, image/archive bombs, size/count/quotas | references/file-uploads.md |
TLS/HSTS, Nginx, reverse-proxy & X-Forwarded-* trust, Gunicorn/systemd hardening, static/media, cache & queue exposure | references/deployment-and-runtime.md |
| Vetted security-library choices, compatibility, minimum-safe versions, conditional/existing-install-only/rejected candidates (current as of 17 Jul 2026) | references/security-hardening-libraries.md |
Cross-references between files are intentional: authz appears in A01 and again, API-shaped, in the DRF file; rate limiting spans A06, A07, uploads, async connections, and the DRF file; deployment covers the infrastructure side of cache and media controls whose application rules live in A01 and the upload reference.
Mode selection
Review-time. Trigger when the user asks to review, audit, scan, or "check" existing code; pastes code and asks whether it's safe; or has just finished a feature and wants it looked at. Behavior:
- Treat the codebase as read-only. Do not edit, refactor, or "fix in place" unless the user explicitly asks you to apply fixes afterward.
- Optionally run the bundled scripts for fast triage (see below), then read the code yourself. Scripts surface indicators; they do not replace judgment.
- Investigate before flagging. Confirm the data flow and the reachability of a sink. Do not pattern-match a keyword into a finding.
- Produce a findings report in the exact format in
references/00-methodology-and-severity.md: ordered by severity, each with location, CWE, OWASP mapping, and a concrete fix. End with what you did not review.
Write-time. Trigger when you're generating or modifying backend code for a feature. Behavior:
- Apply the secure defaults from the relevant category file(s) as you write — parameterized queries, scoped querysets, explicit serializer fields, correct cookie/security flags, safe deserializers, secrets from the environment.
- Prefer built-in framework mechanisms over add-ons (see the libraries file).
- Briefly note the security-relevant choices you made. If a requirement forces a risky pattern, say so and describe the residual risk rather than hiding it.
If it's ambiguous, default to write-time guardrails while coding and offer to run a review afterward.
Using the scripts
Both scripts are read-only, stdlib-only, and make no network calls. Run them for triage; always confirm what they surface by reading the code.
- Settings posture (AST-based; never imports the project):
python scripts/settings_scan.py path/to/settings.py - Risky-pattern indicators across a tree:
python scripts/dangerous_patterns.py path/to/project
Their output is a starting point for investigation, not a final report. Map each real issue to a category file, verify it, and write it up per the methodology.
Severity, in one line each
- Critical — trivially exploitable; RCE, full auth bypass, mass data exposure, or financial/payment manipulation.
- High — directly exploitable under realistic conditions; account takeover, privilege escalation, significant data exposure.
- Medium — exploitable given specific conditions, or a meaningful defense-in-depth gap.
- Low — hardening / defense-in-depth with limited direct impact.
Report findings you're ≥80% confident are real and reachable. Full rubric and
report template: references/00-methodology-and-severity.md.