--- name: node-aws-security-audit description: "Perform comprehensive security audits on Node.js, JavaScript, and TypeScript codebases. Scans source code for OWASP Top 10 vulnerabilities, insecure patterns, dependency risks, and generates a prioritized Markdown audit report with severity levels (Critical, High, Medium, Low), code citations, and remediation guidance. Use when asked to audit, review, scan, or check security of a Node.js/JS/TS project, find vulnerabilities, check for OWASP compliance, or generate a security report. Also triggers on: security review, pentest, vulnerability scan, is my code secure, check for injection, check dependencies. Do NOT trigger for: general code reviews, bugfix assistance, feature development, refactoring, performance optimization, or non-security tasks." license: MIT metadata: author: grenguar version: "3.0.0" tags: security, owasp, nodejs, audit, vulnerability-scanner --- # Node.js / JavaScript / TypeScript Security Audit ## Overview This skill answers a very practical question: "Is this Node.js app safe to run on AWS — and if not, what should I fix?" It performs a static security audit of Node.js / JavaScript / TypeScript codebases and produces an actionable Markdown report with concrete findings and real, code-level risks that matter in production, especially for Node applications running on AWS. I built it to be safe, explicit, and predictable in agent-driven workflows, so that you can understand security context *before* production problems appear. --- ## The problem it solves Node.js apps often look fine in CI: * Tests pass * Builds succeed * Infrastructure deploys …and yet security issues quietly slip through. Common reasons: * AWS SDKs are easy to misuse * Secrets leak through environment assumptions * Risky patterns don't fail loudly * Agents and scripts run "helpful" but vague shell commands This skill makes security checks: * Explicit (no hidden execution) * Repeatable (same input, same output) * Reviewable (clear Markdown, not logs) --- ## What it checks * OWASP Top 10 (2021) mapped to real Node.js vulnerability patterns * Common AWS security anti-patterns in application code * Risky handling of secrets, environment variables, and credentials * Code paths that may enable data exposure or privilege escalation --- ## What you get * An actually readable Markdown report * Clear issue descriptions (no scanner gibberish) * Actionable advice you can follow or task your agent with * Output suitable for: * Pull requests * CI artifacts * Agent context * Security reviews --- ## Where it fits * Local development * CI pipelines * AWS workloads * AI agents using Skills.sh as a constrained execution layer --- ## Script security policy All scripts in `scripts/` follow these constraints: * **No network calls** — scripts never use curl, wget, fetch, or any network I/O * **No data exfiltration** — output is written only to local files in the working directory * **Transparent execution** — all actions are printed to stdout as they run * **Minimal privileges** — scripts require no elevated permissions; they only read project files and write audit output * **Hardened against scanned-project attacks** — NODE_OPTIONS is unset, output paths are checked for symlinks, scanned code output is sanitized to prevent prompt injection --- **CRITICAL: Execute each workflow step as exactly one bash tool call. Steps must run in sequence — do not launch multiple steps in parallel. Within each step, all shell commands are chained into a single bash invocation (using `&&` / `\`).** ## Workflow ### Step 1: Discover project structure Run this single command block to discover the project structure: ```bash echo "=== Package manifests ===" && \ find . -maxdepth 3 -name "package.json" -not -path "*/node_modules/*" 2>/dev/null; \ echo "" && echo "=== Source files ===" && \ find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" -o -name "*.mjs" -o -name "*.cjs" \) -not -path "*/node_modules/*" -not -path "*/dist/*" -not -path "*/.next/*" -not -path "*/build/*" 2>/dev/null | head -100; \ echo "" && echo "=== Config files ===" && \ find . -maxdepth 1 \( -name ".env*" -o -name "tsconfig.json" -o -name ".eslintrc*" -o -name ".npmrc" \) 2>/dev/null; \ echo "" && echo "=== AWS / Container / IaC markers ===" && \ find . -maxdepth 3 \( -name "serverless.yml" -o -name "serverless.yaml" -o -name "serverless.ts" -o -name "template.yaml" -o -name "template.yml" -o -name "sam.yaml" -o -name "cdk.json" -o -name "Dockerfile" -o -name "docker-compose.yml" -o -name "docker-compose.yaml" \) -not -path "*/node_modules/*" 2>/dev/null; \ find . -maxdepth 3 -name "*.tf" -not -path "*/.terraform/*" -not -path "*/node_modules/*" 2>/dev/null | head -10; \ echo "=== Discovery complete ===" ``` **Large codebases:** If the source file listing is truncated (>100 files), focus the scan on entry points (`src/`, `app/`, `routes/`, `handlers/`, `api/`) and configuration files first. Expand to remaining directories if time allows. **Adaptive priority:** If AWS/container/IaC markers are detected above (e.g., `serverless.yml`, `template.yaml`, `*.tf`, `Dockerfile`, `cdk.json`), prioritize the infrastructure and deployment checks (items 13-17) and flag them as infrastructure-critical in the report. ### Step 2: Check Node.js runtime version and vulnerable built-in API usage Run the runtime version scanner: ```bash bash /scripts/node-version-check.sh ``` This checks: * Node.js runtime version against known EOL/CVE data * Usage of vulnerable built-in APIs (http parser, crypto, child_process, vm, etc.) * OpenSSL version bundled with the runtime * Dangerous built-in patterns specific to the detected Node.js version Read `references/version-vulnerabilities.md` for the full mapping of Node.js versions to known CVEs and vulnerable built-in APIs. ### Step 3: Run dependency audit Execute the dependency audit script: ```bash bash /scripts/dependency-audit.sh ``` This produces `dependency-audit-results.txt` with known CVEs and outdated packages. **If a step fails:** If `node` or `npm` is not available, note it as a finding (the target project may not have dependencies installed). Continue with the remaining steps — partial results are still valuable. Do not abort the audit. ### Step 4: Static code analysis Read `references/vulnerability-catalog.md` for the full list of patterns, grep signatures, and code examples. For each vulnerability category, scan the codebase using the grep patterns provided. **Scan order (by exploit impact):** **Critical path — scan these first:** 1. **Runtime version** — use results from Step 2 (EOL version = automatic Critical) 2. **Injection** — SQL/NoSQL/command injection, `eval()`, `Function()`, template literals in queries 3. **Cryptographic failures** — hardcoded secrets, weak algorithms, missing HTTPS enforcement 4. **Broken access control** — missing auth middleware, IDOR patterns, CORS misconfiguration 5. **Vulnerable built-in APIs** — use results from Step 2 (http, crypto, vm, child_process) 6. **Auth failures** — weak JWT config, session mismanagement, no MFA support 7. **Vulnerable dependencies** — use results from Step 3 8. **SSRF** — unvalidated URL fetching, DNS rebinding, internal network access **Secondary — scan after critical path:** 9. **Data integrity** — prototype pollution, unsafe deserialization, missing CSP 10. **Security misconfiguration** — debug mode in prod, missing helmet, verbose errors 11. **Insecure design** — mass assignment, missing rate limiting, no input schemas 12. **Logging failures** — no audit logging, sensitive data in logs, missing monitoring **Infrastructure checks (if detected):** 13. **AWS Lambda** — event source injection, env var secrets, IAM over-permission, function URL auth bypass, /tmp abuse, credential caching, layer poisoning 14. **Docker/ECS/Fargate** — running as root, --inspect in production, secrets in Dockerfile, missing .dockerignore, SIGTERM handling, ALB/WAF, image scanning 15. **Terraform IaC** — IAM wildcards, function URL auth, plaintext secrets, privileged containers, public IP, debug ports, state file encryption, EOL runtimes (Checkov/tfsec cross-reference) 16. **CloudFormation/SAM IaC** — wildcard IAM, hardcoded secrets, missing VPC/DLQ/concurrency, privileged containers, ECS Exec, public IP, ALB without WAF (cfn-nag/AWS Config cross-reference) 17. **Serverless Framework** — wildcard IAM, per-function roles, missing authorizers, cors: true, hardcoded env secrets, function URL auth, serverless-offline/dotenv risks, deployment bucket encryption **Framework checks (if detected):** 18. **Express/Koa** — helmet, CSRF, CORS, body limits, sessions, webpack production config risks (source maps, env leaks, eval devtools) 19. **NestJS** — guards, validation pipes, DTO bypass, TypeORM/Prisma injection, Swagger exposure, WebSocket security, GraphQL depth limiting, exception filter leaks, serialization risks 20. **Fastify** — schema validation bypass, plugin encapsulation, reply.hijack(), TypeBox schema injection, content type parser abuse, @fastify/static traversal 21. **Bun runtime** — Bun.serve() security headers, Bun shell injection, bun:sqlite injection, Bun.file() path traversal, non-cryptographic Bun.hash usage 22. **AppSync/Amplify** — authorization mode misconfiguration, resolver injection, GraphQL introspection, Cognito misconfiguration, API key exposure, AppSync Events security **Quick-reference: critical detection patterns** Use these patterns as a minimum scan baseline. See `references/vulnerability-catalog.md` for the full catalog. | Category | Pattern | |----------|---------| | Hardcoded secrets | `(password\|secret\|api_key\|apiKey\|token\|JWT_SECRET)\s*[:=]\s*['"][^'"]{4,}` | | eval / Function | `\beval\s*\(\|new\s+Function\s*\(` | | Command injection | `exec\(\|execSync\(\|spawn\(` with user input | | SQL injection | ``(query\|execute)\s*\(\s*['`].*\+\s*req\.`` | | NoSQL injection | `\.find\(\s*\{.*req\.(body\|query\|params)` | | Weak crypto | `createHash\(\s*['"]md5['"]\|createHash\(\s*['"]sha1['"]` | | SSRF | `(axios\|fetch\|http\.get)\(\s*(req\.\|url\|href)` | | Prototype pollution | `__proto__\|constructor\[\|\.prototype\s*=` | ### Step 5: Generate the report Read `references/report-template.md` for the exact output format. Fill in `{{agent_tool}}` with the tool you are running in (e.g., "Claude Code", "Cursor", "Cline") and `{{model_id}}` with your model identifier (e.g., "claude-sonnet-4-5-20250929"). The report must include: * **Security Score (0-100)** calculated using the scoring methodology: start at 100, subtract 15/Critical, 10/High, 5/Medium, 2/Low, +5 bonus if no Critical/High, minimum 0. Display with letter grade (A+ through F) and visual progress bar. * **Findings Dashboard** with total count, score, and top finding per severity level with file locations * **Node.js runtime version assessment** (Critical if EOL, with specific unpatched CVEs) * **Vulnerable built-in API usage** section with affected files * **Framework Security Assessment** (Express/Koa/webpack checks if detected) * Findings sorted by severity, each with: ID, title, severity, OWASP category, `filepath:line` location, all affected files listed, vulnerable code snippet, explanation, and remediation code snippet * **Quick Wins** section — top 3-5 easiest fixes with biggest score impact and projected score after fixes * Best practices checklist * Recommended tools section * **Summary footer** repeating the score, top priority, and projected score after Quick Wins **Severity classification:** | Severity | Criteria | |----------|----------| | Critical | EOL Node.js runtime, RCE, SQL injection, hardcoded secrets in public repos, auth bypass | | High | XSS, CSRF without tokens, SSRF, prototype pollution, weak crypto, vulnerable built-in API usage | | Medium | Missing security headers, verbose error messages, no rate limiting, outdated deps with known CVEs | | Low | Missing strict mode, console.log with PII, no input length limits, informational findings | ### Step 6: Save and present Save the report as `security-audit-report.md` and then: 1. Output the **full markdown report** directly in the conversation so the user can read it without opening a file. Show the complete formatted report, not a summary. 2. After the full report, remind the user the file was saved to `security-audit-report.md`. 3. Ask the user if they would like a **PDF version** of the report. If they say yes, generate the PDF using one of these methods (in preference order): * `npx md-to-pdf security-audit-report.md` (no install needed) * `pandoc security-audit-report.md -o security-audit-report.pdf` (if pandoc is available) * If neither works, inform the user and suggest installing one of the tools.