The OWASP Top 10 Changed in 2025: What Web Developers Need to Do Differently

The OWASP Top 10:2025 introduced two new categories, moved Security Misconfiguration up to second place, and folded Server-Side Request Forgery into Broken Access Control. The bigger shift is conceptual: OWASP moved its focus from isolated coding flaws toward the security of the entire software ecosystem, with much heavier weight on supply chain and configuration. Broken Access Control stayed at number one.

If you last read this list in 2021, three things changed enough to affect what you actually do.

1. Broken Access Control still leads, and now includes SSRF

Access control failures remain the most serious application security risk. What changed is scope: Server-Side Request Forgery, which had its own category in 2021, is now part of this one.

That reclassification makes sense once you see the logic. SSRF is an access control failure where the thing exceeding its permissions is your server rather than a user. An attacker convinces your backend to fetch a URL it should not be allowed to reach, usually something on your internal network.

// Vulnerable: fetches whatever the user asks for app.post('/preview', async (req, res) => { const html = await fetch(req.body.url).then(r => r.text()); res.send(html); }); // Better: allowlist, resolve DNS, and reject private ranges const ALLOWED_HOSTS = new Set(['images.example.com', 'cdn.example.com']); app.post('/preview', async (req, res) => { const url = new URL(req.body.url); if (url.protocol !== 'https:' || !ALLOWED_HOSTS.has(url.hostname)) { return res.status(400).send('Host not allowed'); } const html = await fetch(url).then(r => r.text()); res.send(html); });

An allowlist is the only approach that holds up here. Blocklisting private IP ranges gets defeated by DNS rebinding, redirects, and creative IP encodings, and people have spent years discovering new bypasses.

2. Security Misconfiguration jumped from #5 to #2

This is the change I would pay most attention to, because it is the one that says the industry's bugs have moved. Misconfiguration is not a coding mistake. It is a default left in place, a permission set too wide, a debug endpoint that shipped, a storage bucket that was never locked down.

The reason it climbed is that modern applications have vastly more configuration surface than they did in 2021. Every managed service, every IaC template, every container image, every CI pipeline has settings that are insecure by default or become insecure when combined.

The practical response is treating configuration as code that gets reviewed. Specifically: no debug or verbose error output in production, no default credentials anywhere, security headers set deliberately rather than inherited, and permissions granted at the narrowest scope that works rather than the widest that is convenient.

// Minimum viable headers, set once at the edge of the app app.use((req, res, next) => { res.setHeader('Content-Security-Policy', "default-src 'self'"); res.setHeader('X-Content-Type-Options', 'nosniff'); res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains'); next(); }); // And make sure this is actually off in production app.set('env', process.env.NODE_ENV); // not left at 'development'

3. Software Supply Chain Failures is a new category

Listed as A03:2025, this absorbs the old Vulnerable and Outdated Components category and broadens it considerably. The old category was about running a dependency with a known CVE. The new one covers the whole path code takes to reach production: the registry, the maintainer's account, the build system, the CI pipeline.

The timing is not coincidental. The self-propagating worms hitting the npm registry over the past year compromised packages with billions of combined monthly downloads, and none of those were "outdated components" in the old sense. They were current versions of well-maintained packages, published by compromised maintainer accounts.

What actually helps, in rough order of value: commit lockfiles and use npm ci rather than npm install in CI, disable install scripts by default and allow them per package, delay adopting brand new versions by a few days, and enable two-factor authentication plus trusted publishing on anything you maintain.

npm config set ignore-scripts true --location=project npm ci # respects the lockfile exactly npm rebuild sharp # allow the ones that genuinely need it

4. Mishandling of Exceptional Conditions is the other new entry

This one covers what happens when your application meets a situation it was not designed for: a timeout, an overload, a malformed input, a dependency that returns something unexpected. The security problem is that error paths are far less tested than happy paths, and an attacker who can trigger an unusual condition often finds the application behaves in ways nobody specified.

The pattern that produces real vulnerabilities is failing open. Code that grants access when a check errors rather than denying it:

// Fails open: an auth service timeout grants access async function canAccess(user, doc) { try { return await authService.check(user, doc); } catch (err) { console.error(err); return true; // wrong, and surprisingly common } } // Fails closed async function canAccess(user, doc) { try { return await authService.check(user, doc); } catch (err) { logger.error({ err, user: user.id, doc: doc.id }, 'authz check failed'); return false; } }

I have found the first version in real codebases more than once, usually added during an incident when the auth service was down and someone needed the site working. It never got reverted.

What I would actually change this week

If you do three things off this list, make them these. Turn off npm install scripts on your projects and see what breaks, which is usually less than you fear. Grep your codebase for catch blocks that return true, grant, or allow, because failing open hides in exactly those places. And check whether your production error responses include stack traces, which is the single most common misconfiguration I find on small sites.

None of those are architectural. They are afternoon-sized, which is why they are worth doing rather than adding to a security backlog nobody gets to.

Reference: OWASP Top 10:2025 and the OWASP Top Ten project page.