jim60105 TypeScript / JavaScript Security Development Guide
Provide a structured approach to building secure TypeScript and JavaScript applications, covering the OWASP Top 10, secure coding patterns, and verification checklists. Apply these guidelines throughout the secure development lifecycle — from threat modeling through deployment. This guide covers both server-side (Node.js, Deno, Bun) and client-side (browser) contexts.
Secure Development Lifecycle
Phase 1: Threat Modeling and Secure Design
Before writing code, identify and mitigate threats at the design level:
- Identify trust boundaries — Map where untrusted data enters the system (HTTP requests, WebSocket messages, file uploads, database reads, environment variables, third-party APIs,
postMessage, URL parameters, localStorage) - Map data flows — Trace sensitive data (credentials, PII, tokens) through the system and verify protection at each stage
- Enumerate entry points — List all routes, endpoints, CLI arguments, message queue consumers, WebSocket handlers, and scheduled tasks
- Map attack surfaces to OWASP Top 10 — Cross-reference each entry point against the OWASP categories in the quick reference table below
Design with security controls built-in:
- Centralized authentication and authorization middleware — never scatter auth checks across handlers
- Input validation at every trust boundary — validate early, reject invalid data before processing
- Least-privilege database access — use read-only connections where writes are not needed
- Defense in depth — layer multiple controls (input validation + parameterized queries + WAF)
- Fail securely — deny by default, require explicit grants
- Server-side enforcement — never rely solely on client-side validation or access controls
Phase 2: Secure Implementation
Critical Prohibitions
Never use these patterns. Violations are high-severity findings in any review.
| Never | Instead |
|---|---|
eval() / Function() constructor with untrusted input |
JSON.parse() or a dedicated parser |
child_process.exec() with user input |
child_process.execFile() or spawn() with array args |
| String concatenation / template literals in SQL | Parameterized queries (db.query(sql, params)) |
innerHTML / outerHTML / document.write() with untrusted data |
textContent, framework templating, or DOMPurify |
dangerouslySetInnerHTML with unsanitized data |
DOMPurify + explicit sanitization |
Math.random() for security purposes |
crypto.randomUUID() / crypto.getRandomValues() |
| MD5 / SHA1 for password hashing | bcrypt, argon2, or scrypt via crypto.scrypt() |
== for security comparisons |
=== strict equality |
Object.assign() / spread with untrusted input on prototypes |
Validated schema (Zod, class-validator) + Object.create(null) |
require() / import() with user-controlled paths |
Static imports with allowlisted modules |
| Hardcoded secrets in source code | Environment variables or secret manager (Vault, AWS SM) |
NODE_ENV !== 'production' left in production |
Environment-specific configuration |
JSON.parse() without schema validation on untrusted data |
Zod, io-ts, or class-validator after parsing |
new RegExp(userInput) |
Escape user input or use a safe regex library |
vm.runInNewContext() / vm.runInThisContext() with untrusted code |
Isolated worker threads or dedicated sandbox |
Disabling TLS verification (rejectUnauthorized: false) |
Proper certificate management |
Secure Implementation References
- For OWASP Top 10 details with vulnerable → secure code examples: See references/owasp-top-10.md
- For secure coding patterns organized by domain (input validation, auth, crypto, DOM security, subprocess, file I/O, web frameworks): See references/secure-coding.md
Phase 3: Security Verification
Apply a layered verification approach:
- Static Analysis — Detect common vulnerability patterns automatically
eslint-plugin-security— Node.js security linter ruleseslint-plugin-no-unsanitized— Detect unsafe DOM manipulationsemgrep— Pattern-based analysis with OWASP and TypeScript/JavaScript rulesetstypescript-eslint— Type-aware linting for TypeScript
- Dependency Audit — Identify known vulnerabilities in third-party packages
npm audit/yarn audit/pnpm audit— Built-in package manager auditingsnyk— Comprehensive vulnerability database and remediation advicesocket.dev— Supply chain attack detection (typosquatting, install scripts)
- Secrets Detection — Find leaked credentials and API keys
detect-secrets— Baseline-aware secrets scannergitleaks— Git-aware secrets scanning
- Code Review — Apply the security review workflow and checklists
- Security Testing — Write negative tests that verify rejection of malicious inputs; fuzz-test parsers and validators
Quick tool commands:
# ESLint security plugins
npm install --save-dev eslint-plugin-security eslint-plugin-no-unsanitized
npx eslint --ext .ts,.js,.tsx,.jsx src/
# npm audit — dependency vulnerabilities
npm audit
npm audit --audit-level=high
# Snyk — comprehensive dependency and code scanning
npx snyk test
npx snyk code test
# detect-secrets — secrets scanning
detect-secrets scan > .secrets.baseline
# Semgrep — advanced pattern matching
semgrep --config=p/javascript --config=p/typescript --config=p/owasp-top-ten src/
# Socket.dev — supply chain security
npx socket npm info <package-name>
For complete verification checklists (code review, architecture review, dependency audit, deployment, testing, incident response): See references/security-checklist.md
Phase 4: Dependency and Deployment Security
Dependency Management
- Use lockfiles (
package-lock.json,yarn.lock,pnpm-lock.yaml) and commit them - Run
npm audit/snyk testin CI/CD pipeline on every build - Enable
--ignore-scriptsfor packages where postinstall scripts are not needed - Monitor for typosquatting — verify package names carefully before installing
- Review new dependencies before adding — check maintainership, download counts, known issues
- Use
socket.devor similar tools to detect supply chain attacks (install scripts, obfuscated code) - Prefer packages with provenance attestations (
npm provenance)
Deployment Hardening
- Container security — Scan images with
trivy; use minimal base images (distroless, alpine); run as non-root user - HTTPS/TLS — Enforce TLS 1.2+ for all connections; redirect HTTP to HTTPS; set
Strict-Transport-Securityheader - Security headers — Configure
Content-Security-Policy,X-Content-Type-Options: nosniff,X-Frame-Options: DENY,Permissions-Policy - Secrets at runtime — Inject secrets via environment variables or mounted volumes; never bake into images or bundles
- Least privilege — Run processes as non-root; use read-only filesystems where possible; limit network access
- Source maps — Never deploy source maps to production in public-facing applications
- Client-side — Enable Subresource Integrity (SRI) for CDN scripts; configure strict CSP; avoid inline scripts
- Logging — Use structured logging (JSON); never log passwords, tokens, PII, or full stack traces to users; log authentication events and access denials for audit
OWASP Top 10:2025 Quick Reference
Map each OWASP 2025 category to TypeScript/JavaScript-specific risks and primary mitigations:
| # | Category | TypeScript/JavaScript-Specific Risks | Primary Mitigation |
|---|---|---|---|
| A01 | Broken Access Control | Missing auth middleware, IDOR via sequential IDs, path traversal, SSRF via fetch(userUrl), CORS origin: *, client-side-only auth checks |
Centralized auth middleware, object-level permissions, path.resolve() + containment check, URL allowlisting, explicit CORS origins |
| A02 | Security Misconfiguration | NODE_ENV=development in prod, Swagger/docs exposed, verbose error stacks, permissive CORS, default express.static() serving .env |
Environment-specific config, disable docs in prod, centralized error handler, explicit CORS, .env outside webroot |
| A03 | Software Supply Chain Failures | Unpinned deps, typosquatting on npm, malicious postinstall scripts, no lockfile, unvetted transitive deps, CI/CD secrets exposure | npm audit / snyk in CI, lockfiles committed, --ignore-scripts, socket.dev, npm provenance |
| A04 | Cryptographic Failures | Math.random() for tokens, weak hashing, hardcoded API keys, disabled TLS verification, secrets in client bundles |
crypto.randomUUID() / crypto.getRandomValues(), bcrypt/argon2, env vars / secret manager, proper TLS config |
| A05 | Injection | SQL via template literals, XSS via innerHTML/dangerouslySetInnerHTML, child_process.exec(), NoSQL injection ($gt/$ne operators), SSTI, eval() |
Parameterized queries, DOM sanitization (DOMPurify), execFile()/spawn() with array args, input validation, textContent |
| A06 | Insecure Design | No rate limiting, missing input validation layer, no abuse case modeling, client-side enforcement of server-side security | Threat modeling, validation at boundaries (Zod/class-validator), rate limiting middleware, server-side enforcement |
| A07 | Authentication Failures | Weak session config, JWT algorithm: "none" or HS256 with public key, no brute-force protection, tokens in localStorage |
Secure session settings, explicit algorithms: ["RS256"], account lockout / rate limiting, HttpOnly cookies |
| A08 | Software or Data Integrity Failures | Prototype pollution, node-serialize deserialization, unsigned updates, CDN scripts without SRI, CI/CD pipeline injection |
Schema validation (Zod), JSON.parse() + validation, SRI for CDN scripts, pinned CI actions with SHA |
| A09 | Security Logging and Alerting Failures | Logging passwords/tokens, console.log in production, no auth event logging, missing alerting, no structured logging |
Structured logging (pino/winston) with field filtering, audit trail, alerting thresholds, honeytokens |
| A10 | Mishandling of Exceptional Conditions | Unhandled promise rejections, empty catch {}, failing open, sensitive info in error responses, uncaught exceptions crashing process |
Specific error types, finally blocks, centralized error handler, process.on('unhandledRejection'), fail-closed patterns |
For detailed vulnerable → secure code examples for each category: See references/owasp-top-10.md
Security Review Workflow
Follow this procedure when reviewing TypeScript or JavaScript code for security:
- Scan for critical prohibitions — Check for any pattern in the "Critical Prohibitions" table above. Each match is an immediate high-severity finding.
- Check input validation — Verify every entry point (route handler, CLI argument, file parser, WebSocket handler, queue consumer) validates and sanitizes input before processing.
- Verify authentication and authorization — Confirm every endpoint requires authentication (unless explicitly public) and checks authorization for the specific resource being accessed.
- Review data handling — Trace how secrets, PII, and sensitive data flow through the system. Verify encryption at rest and in transit, proper key management, and secure deletion. Ensure no secrets are bundled into client-side code.
- Check error handling — Ensure errors do not leak stack traces, internal paths, database details, or configuration to users. Verify fail-secure behavior. Check for unhandled promise rejections.
- Audit dependencies — Run
npm auditandsnyk test. Flag any unpatched dependencies or packages with known CVEs. Check for suspicious postinstall scripts. - Verify logging — Confirm no sensitive data (passwords, tokens, PII) appears in logs. Verify authentication events, authorization failures, and security-relevant actions are logged.
- Run static analysis — Execute ESLint with security plugins and review findings. Run
semgrepwith JavaScript/TypeScript and OWASP rulesets for deeper analysis. - Check DOM security (client-side) — Verify no unsafe DOM manipulation (
innerHTML,document.write). Check CSP configuration, SRI on external scripts, and proper sanitization of user content. - Report findings — For each finding, document: severity (Critical/High/Medium/Low), location (file:line), vulnerable code snippet, explanation of the risk, and recommended fix with code example.
Security Hardening Quick Commands
# === Static Analysis ===
npm install --save-dev eslint-plugin-security eslint-plugin-no-unsanitized
npx eslint --ext .ts,.js,.tsx,.jsx src/
semgrep --config=p/javascript --config=p/typescript --config=p/owasp-top-ten src/
# === Dependency Audit ===
npm audit --audit-level=high
npx snyk test
# === Secrets Detection ===
detect-secrets scan > .secrets.baseline
gitleaks detect --source .
# === Lock Dependencies ===
npm ci # install from lockfile (CI/CD)
# === Container Scanning ===
# trivy image <image-name>
Reference Files
Consult these files for detailed guidance beyond this overview:
- references/owasp-top-10.md — Detailed OWASP Top 10 coverage with TypeScript/JavaScript-specific vulnerable → secure code examples for each category, including Express, Fastify, NestJS, Next.js, and React patterns
- references/secure-coding.md — Secure coding patterns organized by domain: input validation, authentication, cryptography, DOM security, subprocess execution, file operations, and web framework configuration (Express, Fastify, NestJS, Next.js, React)
- references/security-checklist.md — Actionable verification checklists for code review, architecture review, dependency audit, deployment hardening, security testing, and incident response