Security audit
Skill tranhieutt/software_development_department/.claude/skills/security-audit
Software Development Department
npx -y skills add tranhieutt/software_development_department --skill security-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Conducts a comprehensive security audit covering web application vulnerabilities, API security, OWASP Top 10, and security hardening recommendations. Use when auditing a codebase for security or when the user mentions security audit, penetration testing, or vulnerability scan.
SKILL.md
8.2 KB, ~2.2k tokens by cl100k_base, as published. Nobody here has run it
Security Auditing Workflow
Systematic security review using static analysis tools available in the codebase. Covers OWASP Top 10, secrets exposure, auth patterns, and dependency risk.
Phase 1: Reconnaissance — Map the Attack Surface
-
Identify entry points — list all routes/controllers:
grep -rn "app\.\(get\|post\|put\|delete\|patch\)\|@app\.route\|router\." src/ --include="*.{js,ts,py}" | head -60 -
Identify auth middleware — check which routes are protected:
grep -rn "auth\|middleware\|guard\|require_login\|jwt\|bearer" src/ -i --include="*.{js,ts,py}" | head -40 -
Map external dependencies — check package files for known-risky libs:
cat package.json 2>/dev/null || cat requirements.txt 2>/dev/null || cat go.mod 2>/dev/null -
Note findings — list: total endpoints found, unprotected routes, third-party auth libs.
Phase 2: Secrets & Sensitive Data Exposure
-
Scan for hardcoded secrets:
grep -rn "password\s*=\s*['\"][^'\"]\|api_key\s*=\s*['\"][^'\"]\|secret\s*=\s*['\"][^'\"]" src/ -i | grep -v ".example" | head -30 -
Scan for tokens/keys in source:
grep -rEn "(sk-|AIza|AKIA|ghp_|xox[baprs]-)[A-Za-z0-9]+" src/ | head -20 -
Check .env files are gitignored:
cat .gitignore | grep -i "\.env" ; ls -la .env* 2>/dev/null -
Check for secrets in logs:
grep -rn "console\.log.*password\|logger.*token\|print.*secret" src/ -i | head -20
Flag: any hardcoded credential or unignored .env file is a P0 finding.
Phase 3: Injection & Input Validation
-
SQL injection risk — look for string concatenation in queries:
grep -rn "query.*+\|execute.*f\"\|raw.*%s\|SELECT.*\$\{" src/ --include="*.{js,ts,py}" | head -30 -
Command injection risk — shell execution with user input:
grep -rn "exec(\|spawn(\|subprocess\|os\.system\|child_process" src/ --include="*.{js,ts,py}" | head -20 -
XSS risk — unescaped HTML rendering:
grep -rn "innerHTML\|dangerouslySetInnerHTML\|v-html\|\.html(" src/ --include="*.{js,ts,jsx,tsx,vue}" | head -20 -
Check for input validation middleware — is there a schema validator at boundaries?
grep -rn "joi\|zod\|yup\|pydantic\|cerberus\|marshmallow" src/ --include="*.{js,ts,py}" | head -10
Phase 4: Authentication & Authorization
-
JWT / token handling — check for weak configs:
grep -rn "algorithm.*HS256\|expiresIn\|verify\|decode" src/ --include="*.{js,ts,py}" | head -20 -
Password hashing — confirm bcrypt/argon2, not MD5/SHA1:
grep -rn "md5\|sha1\|hashSync\|bcrypt\|argon2\|pbkdf2" src/ -i --include="*.{js,ts,py}" | head -20 -
CORS config — check for wildcard origins:
grep -rn "cors\|Access-Control-Allow-Origin\|\*" src/ --include="*.{js,ts,py}" | head -20 -
Authorization checks — look for missing ownership checks in update/delete:
grep -rn "findById\|findOne\|get_object_or_404" src/ --include="*.{js,ts,py}" | head -20Review each — does the handler verify
resource.userId === req.user.id?
Phase 5: Security Headers & Config
-
HTTP security headers — check if helmet/similar is configured:
grep -rn "helmet\|Content-Security-Policy\|X-Frame-Options\|Strict-Transport" src/ --include="*.{js,ts}" | head -10 -
Rate limiting — check for brute-force protection on auth routes:
grep -rn "rateLimit\|throttle\|rate_limit\|slowDown" src/ --include="*.{js,ts,py}" | head -10 -
HTTPS enforcement — check redirect config:
grep -rn "http://\|forceHttps\|redirectToHttps\|SECURE_SSL_REDIRECT" src/ --include="*.{js,ts,py}" | head -10
Phase 6: Report Findings
For each finding, record:
| Severity | Category | File:Line | Description | Remediation |
|---|---|---|---|---|
| P0 Critical | ||||
| P1 High | ||||
| P2 Medium | ||||
| P3 Low / Info |
Severity guide:
- P0: Hardcoded credential, remote code execution, auth bypass
- P1: SQL injection, XSS, IDOR, broken auth
- P2: Missing rate limit, weak hashing, CORS wildcard
- P3: Missing security header, verbose errors, info disclosure
Save report to docs/technical/security-audit-{YYYY-MM-DD}.md.
Security Checklist
OWASP Top 10
- A01 Broken Access Control — ownership checks on every mutation
- A02 Cryptographic Failures — no hardcoded secrets, strong hashing
- A03 Injection — parameterized queries, no string concat in SQL/shell
- A04 Insecure Design — auth required on all sensitive routes
- A05 Security Misconfiguration — security headers, CORS, HTTPS
- A06 Vulnerable Components — no known-CVE dependencies
- A07 Auth & Session — JWT config, expiry, refresh token rotation
- A08 Integrity Failures — no unverified package installs in CI
- A09 Logging & Monitoring — no secrets in logs, audit trail exists
- A10 SSRF — no unvalidated URL-fetch from user input
Protocol
- Question: Reads target scope from argument (
api/frontend/backend/infra/full) - Options: Skip
- Decision: Skip — audit is comprehensive; scope from argument
- Draft: Findings table shown in conversation before saving report
- Approval: "May I write to
docs/technical/security-audit-[YYYY-MM-DD].md?"
Output
Deliver exactly:
- Findings table with severity (P0–P3), file:line, description, and remediation for each issue
- OWASP Top 10 checklist — 10 items marked pass / fail / N/A
- Report file saved to
docs/technical/security-audit-{YYYY-MM-DD}.md - Verdict:
CLEAN/LOW RISK/MEDIUM RISK/HIGH RISK — DO NOT DEPLOY
Secure Coding Reference
When the audit finds a vulnerability and the fix requires hands-on secure coding guidance, apply the following patterns inline (no separate skill needed).
Backend Secure Coding Patterns
- Input validation: allowlist approach — reject anything not explicitly allowed
- Injection prevention: parameterized queries only; never string-concat into SQL/shell
- Auth: bcrypt or Argon2 for passwords; JWT with expiry + rotation; PKCE for OAuth
- CORS: explicit origin allowlist; never
Access-Control-Allow-Origin: *on credentialed routes - CSRF: HttpOnly + SameSite=Strict cookies; double-submit or synchronizer token for mutations
- SSRF: URL allowlist before any server-side fetch; block internal IP ranges
- Error handling: never expose stack traces or internal paths to API consumers
- Secrets: never hardcode; use env vars + secret manager; rotate on suspected exposure
Frontend Secure Coding Patterns
- XSS: prefer
textContentoverinnerHTML; sanitize with DOMPurify if HTML is required - CSP: configure
Content-Security-Policywith nonce-based script restrictions; report-only first - Token storage: HttpOnly cookies over localStorage for session tokens
- Redirects: validate destination against allowlist before any client-side navigation
- SRI: use
integrity=attribute on all third-party script/style tags from CDN - Clickjacking: set
X-Frame-Options: DENYor CSPframe-ancestors 'none'at server level - Open redirect: never use raw query params as redirect destinations; use identifier mapping
Related Skills
code-review— line-by-line review with security lensguard— freeze check before deploying a fix