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:

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 <skill-path>/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 <skill-path>/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:

1. •Data integrity — prototype pollution, unsafe deserialization, missing CSP
2. •Security misconfiguration — debug mode in prod, missing helmet, verbose errors
3. •Insecure design — mass assignment, missing rate limiting, no input schemas
4. •Logging failures — no audit logging, sensitive data in logs, missing monitoring

Infrastructure checks (if detected):

1. •AWS Lambda — event source injection, env var secrets, IAM over-permission, function URL auth bypass, /tmp abuse, credential caching, layer poisoning
2. •Docker/ECS/Fargate — running as root, --inspect in production, secrets in Dockerfile, missing .dockerignore, SIGTERM handling, ALB/WAF, image scanning
3. •Terraform IaC — IAM wildcards, function URL auth, plaintext secrets, privileged containers, public IP, debug ports, state file encryption, EOL runtimes (Checkov/tfsec cross-reference)
4. •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)
5. •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):

1. •Express/Koa — helmet, CSRF, CORS, body limits, sessions, webpack production config risks (source maps, env leaks, eval devtools)
2. •NestJS — guards, validation pipes, DTO bypass, TypeORM/Prisma injection, Swagger exposure, WebSocket security, GraphQL depth limiting, exception filter leaks, serialization risks
3. •Fastify — schema validation bypass, plugin encapsulation, reply.hijack(), TypeBox schema injection, content type parser abuse, @fastify/static traversal
4. •Bun runtime — Bun.serve() security headers, Bun shell injection, bun:sqlite injection, Bun.file() path traversal, non-cryptographic Bun.hash usage
5. •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.

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:

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.