The OWASP Top 10 for JavaScript Developers

The OWASP Top 10 is the closest thing the web security community has to a canonical list of what actually gets applications breached. Reading it in the abstract is not that useful. Reading it through the lens of a JavaScript/Node.js stack—Express routes, MongoDB documents, React frontends, JWT auth—is.

This post maps each category to the patterns you encounter day to day. For a broader threat landscape, see Common Web Security Threats and How to Prevent Them.

A01: Broken Access Control

The number-one risk. Access control breaks when the server trusts the client to identify what it is allowed to touch.

Common JS patterns:

• Using req.body.userId from the client instead of req.user.id from the verified token.
• Fetching a document by ID without checking it belongs to the authenticated user.
• Missing authorization middleware on a route because it was added in a hurry.

ts
// Vulnerable: trusts client-supplied userId
app.get("/api/orders/:id", async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order); // returns any user's order
});

// Fixed: verifies ownership against the authenticated token
app.get("/api/orders/:id", authenticate, async (req, res) => {
  const order = await Order.findOne({
    _id: req.params.id,
    userId: req.user.id,  // ownership check
  });
  if (!order) return res.status(404).json({ error: "Not found" });
  res.json(order);
});

For JWT authentication specifics, see How Modern Authentication Works.

A02: Cryptographic Failures

Previously called "Sensitive Data Exposure." This covers transmitting or storing data without adequate protection.

• Never store passwords in plaintext or with MD5/SHA-1. Use bcrypt or Argon2. See Secure Password Storage with bcrypt and Argon2.
• Never store JWTs in localStorage. See Why You Should Never Store JWT in LocalStorage.
• Use HTTPS everywhere and set Strict-Transport-Security.
• Avoid exposing internal IDs or secrets in API responses (over-fetching).

A03: Injection

Injection means passing attacker-controlled data to an interpreter—SQL, NoSQL, OS command, or LDAP—in a way that changes the query's meaning.

MongoDB NoSQL injection is underappreciated in the JS world:

ts
// Vulnerable: operator injection
const user = await User.findOne({ username: req.body.username });
// If req.body.username = { $ne: null }, this returns the first user in the DB

// Fixed: validate input type first
const { username } = CreateUserSchema.parse(req.body); // z.string()
const user = await User.findOne({ username });

Validating types before they reach the database eliminates operator injection entirely. See Runtime Validation in TypeScript with Zod.

A04: Insecure Design

Insecure design is when the threat model was never considered, not just when a control was implemented poorly. Rate-limit your login endpoint. Implement account lockout. Design password-reset flows so they don't leak whether an email exists.

A05: Security Misconfiguration

• Leaving DEBUG=true in production, exposing stack traces in API responses.
• Default Express headers (X-Powered-By: Express) that fingerprint your stack.
• Open CORS policies (Access-Control-Allow-Origin: *) on authenticated endpoints.
• Exposing .env files or admin routes without authentication.

For secrets management, see Environment Variables and Secrets Management in Next.js.

A06: Vulnerable and Outdated Components

Your node_modules tree is a large, shifting dependency surface. Run npm audit regularly and keep dependencies current. Pay particular attention to transitive dependencies—the left-pad and event-stream incidents both came from transitive packages, not direct dependencies.

Automate dependency updates with tools like Renovate or Dependabot in CI. See CI/CD for Next.js with GitHub Actions for pipeline setup.

A07: Identification and Authentication Failures

• No rate limiting on /login allows credential stuffing.
• Weak session IDs or predictable tokens.
• Missing expiry on password-reset links.
• No multi-factor option on privileged accounts.

For implementing rate limiting, see Rate Limiting Your Next.js APIs.

A08: Software and Data Integrity Failures

This covers insecure deserialization and CI/CD pipeline attacks. In the JS world:

• Avoid eval(), new Function(), and JSON.parse() on untrusted strings without prior validation.
• Be careful with child_process.exec() and shell interpolation.
• Verify the integrity of third-party scripts loaded from CDNs using Subresource Integrity (SRI) hashes.

html
<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha384-abc123..."
  crossorigin="anonymous"
></script>

A09: Security Logging and Monitoring Failures

Most breaches are discovered weeks or months after they begin, often by a third party. The countermeasure is structured logging with alerting on anomalous patterns.

Log: authentication failures, authorization denials, input validation errors, rate-limit hits, admin actions. Include: timestamp, user ID (if available), IP, endpoint, and a short reason string. Never log passwords, tokens, or PII.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when your server makes an HTTP request to a URL supplied by the user, allowing an attacker to reach internal services (metadata endpoints, Redis, internal APIs) that are not exposed externally.

ts
// Vulnerable
app.post("/fetch-preview", async (req, res) => {
  const html = await fetch(req.body.url).then(r => r.text());
  res.send(html);
});

// Mitigated: parse and allowlist
import { URL } from "url";
const ALLOWED_HOSTS = new Set(["api.example.com", "cdn.example.com"]);

app.post("/fetch-preview", async (req, res) => {
  const parsed = new URL(req.body.url); // throws on invalid URL
  if (!ALLOWED_HOSTS.has(parsed.hostname)) {
    return res.status(400).json({ error: "Host not allowed" });
  }
  const html = await fetch(parsed.href).then(r => r.text());
  res.send(html);
});

Putting It Together

The OWASP Top 10 is not a checklist to complete once and forget. It describes recurring architectural patterns that reappear in every generation of technology. For JavaScript developers specifically:

• Validate and type all input before use.
• Authenticate and authorize every request independently.
• Keep dependencies audited and updated.
• Log anomalies and set up alerting.
• Think about the threat model at design time, not after a breach.

For deep dives on individual issues from this list, see Preventing XSS in React and Next.js, CSRF Protection in Modern Web Apps, and Securing REST APIs: Best Practices. If you want to discuss your specific security architecture, reach out via the contact page.