The OWASP Top 10 is the industry reference for web application risk. It is also written for large organizations, which makes it easy to dismiss when you are one person. Here it is translated into what actually threatens a small app.
One thing first, because many guides on this topic are now out of date: the list changed. The categories from the 2021 edition have been reordered, two are new, and one no longer stands alone. Everything below follows the current edition, with vulnerable code and the fix for the items a solo developer is most likely to have shipped.
Which OWASP Top 10 is current in 2026?
The current edition is the OWASP Top 10:2025. OWASP's project page states that the most current released version is the 2025 one, and it replaces the 2021 list. There is no separate 2026 edition. If a guide still lists Server-Side Request Forgery as its own tenth category, it is describing the 2021 list.
These are the ten categories, in OWASP's order and with OWASP's names:
- A01:2025 Broken Access Control
- A02:2025 Security Misconfiguration
- A03:2025 Software Supply Chain Failures
- A04:2025 Cryptographic Failures
- A05:2025 Injection
- A06:2025 Insecure Design
- A07:2025 Authentication Failures
- A08:2025 Software or Data Integrity Failures
- A09:2025 Security Logging and Alerting Failures
- A10:2025 Mishandling of Exceptional Conditions
OWASP's introduction to the 2025 edition summarises the change as two new categories and one consolidation. Software Supply Chain Failures is an expansion of the 2021 category Vulnerable and Outdated Components. Mishandling of Exceptional Conditions is new. Server-Side Request Forgery has been rolled into Broken Access Control. Security Misconfiguration moved from fifth to second, and Cryptographic Failures, Injection and Insecure Design each dropped two places.
The ranking is not opinion alone. OWASP says the edition draws on contributed data for over 2.8 million applications, that eight of the ten categories come from that data, and that the other two come from its community survey.
Does the OWASP Top 10 apply to a solo developer?
Yes, but as a map, not a compliance exercise. OWASP describes the Top 10 as a standard awareness document representing broad consensus on the most critical web application risks. Attackers and automated scanners do not check your headcount. What changes for one person is the order: start with the categories you have most likely shipped.
You do not need to memorize the list. You need to know which items you are most likely to have shipped, and check those.
The sections below group the ten by how a small app tends to meet them, rather than walking through them as ten equal chapters.
The top two: access control and misconfiguration
Broken Access Control (A01)
Still the number one risk. OWASP's contributed data shows that on average 3.73% of applications tested had at least one of the 40 weaknesses mapped to this category. The most common indie version is simple: an endpoint that checks you are logged in but not that the record belongs to you. If /api/orders/123 returns anyone's order, that is broken access control.
// Vulnerable: any logged-in user can read any order
app.get('/api/orders/:id', requireLogin, async (req, res) => {
const { rows } = await db.query(
'SELECT * FROM orders WHERE id = $1', [req.params.id]);
res.json(rows[0]);
});// Fixed: the query itself enforces ownership
const { rows } = await db.query(
'SELECT * FROM orders WHERE id = $1 AND user_id = $2',
[req.params.id, req.user.id]);
if (!rows[0]) return res.status(404).end();OWASP's prevention list comes down to three habits: deny by default, enforce record ownership, and do it in trusted server-side code where the caller cannot edit the check. If your backend is a hosted database that the browser talks to directly, the rules file is your access control, which is why Firebase security rules that are open by default belong in this category. Server-Side Request Forgery lives here now too: if your server fetches a URL that a user supplied (a link preview, a webhook, an image import), restrict where it is allowed to go.
Security Misconfiguration (A02)
Debug mode on in production, default credentials left in place, verbose error messages that leak stack traces. OWASP's own list adds missing security headers and misconfigured cloud permissions, and its data shows that 3.00% of applications tested had at least one weakness here.
A concrete example from the Express documentation: the default error handler puts err.stack in the response body unless the app runs in production mode, which you enable by setting NODE_ENV to production. One missing environment variable and every crash hands a stranger your file paths. This category is pure carelessness, which means it is entirely preventable. The cloud-side version is covered in insecure defaults in infrastructure as code.
What is a software supply chain failure?
A software supply chain failure is a compromise that reaches your app through something you did not write: a dependency, a build tool, a CI pipeline or a package registry. OWASP's 2025 edition widened the old Vulnerable and Outdated Components category to cover this whole ecosystem, and half of its community survey respondents ranked it first.
This is A03, and OWASP's own example is the one to remember. The Shai-Hulud attack in 2025 was, in OWASP's words, the first successful self-propagating npm worm. Malicious package versions ran a post-install script that harvested sensitive data, detected npm tokens in the victim's environment and used them to publish infected versions of every package those tokens could reach. OWASP puts the spread at over 500 package versions before npm disrupted it. A solo developer with a publish token and cloud keys on one laptop is exactly the host that worm needed.
Three habits cover most of it:
- Commit your lockfile and deploy with
npm ci. Per the npm docs, it exits with an error when the lockfile andpackage.jsondisagree and never rewrites either file. - Run
npm audit --audit-level=highin CI. The flag sets the severity at which the command exits non-zero and fails the build. - Delete dependencies you no longer use, and watch for ones that have stopped shipping security patches.
Software or Data Integrity Failures (A08) is the neighbour. A03 is about what you pull in. A08 is about trusting code or data without verifying it: an auto-update with no signature check, a pipeline that runs unverified code, or serialized data that the client could see and modify. The small-app version is a role or a price kept in an unsigned cookie or a hidden form field and believed when it comes back.
The classics: cryptography, injection and authentication
Cryptographic Failures (A04)
Down from second to fourth, with 3.80% of applications affected on average in OWASP's data. One of the questions OWASP asks under this category is whether crypto keys are checked into source code repositories, so hardcoded secrets and leaked API keys count here. For passwords, OWASP names Argon2, yescrypt, scrypt and PBKDF2-HMAC-SHA-512 as acceptable salted hashing functions. For data in transit it calls for TLS 1.2 or higher.
Injection (A05)
User input treated as code. SQL injection is the classic, but it also shows up in NoSQL queries, shell commands, and template rendering, and OWASP files cross-site scripting here as well.
// Vulnerable: input becomes part of the SQL text
db.query(`SELECT * FROM users WHERE email = '${email}'`);
// Fixed: input travels separately as a parameter
db.query('SELECT * FROM users WHERE email = $1', [email]);The node-postgres documentation warns that concatenating parameters into query text "can (and often does) lead to sql injection vulnerabilities". The fix is always the same: parameterize, never concatenate.
Authentication Failures (A07)
Small apps get these wrong because auth is copied, not understood. OWASP's prevention list is practical: enforce multi-factor authentication where you can, never ship default credentials, check new passwords against breached-password lists, and limit or delay failed logins. It also recommends preferring a well-tested existing system over writing your own, and validating the aud and iss claims on tokens. The token side is covered in JWT authentication mistakes that ship to production.
Design, logging and failing closed
Insecure Design (A06)
OWASP's line on this is worth quoting: an insecure design "cannot be fixed by a perfect implementation". Its example scenarios include a booking system that lets one attacker reserve hundreds of seats and a shop with no protection against bots buying out stock. The indie equivalent is an endpoint that calls a paid API with no per-user limit, which is how you end up with a denial-of-wallet serverless bill. The design question to ask: what is the most expensive thing a signed-in stranger can do a thousand times?
Security Logging and Alerting Failures (A09)
Renamed slightly in 2025 to stress alerting, and voted in by the community rather than the data. You do not need a SIEM. Log failed logins and access control failures with a user ID and a timestamp, keep the logs somewhere other than the server itself, and set one alert for a spike. Keep secrets and tokens out of the logs.
Mishandling of Exceptional Conditions (A10)
New in 2025, with 24 mapped weaknesses including CWE-209 (error messages containing sensitive information) and CWE-636 (not failing securely, also called failing open). Failing open looks like this:
// Vulnerable: if the lookup throws, the request continues
async function requireAdmin(req, res, next) {
try {
const user = await getUser(req);
if (!user.isAdmin) return res.status(403).end();
} catch (err) {
console.error(err);
}
next();
}// Fixed: an error is a refusal
try {
const user = await getUser(req);
if (!user.isAdmin) return res.status(403).end();
next();
} catch (err) {
console.error(err);
res.status(500).end();
}OWASP's guidance is to catch errors where they occur, fail closed, and roll back the whole transaction when a multi-step operation is interrupted.
Where should a solo developer start with the OWASP Top 10?
Start with the categories that are both common and cheap to check: access control on every endpoint that takes an ID, production configuration, secrets in your repository, and your dependency lockfile. Those four cover the top four categories of the 2025 list and can be checked in one evening without any security background.
The full pass, one step per category:
- For every route that takes an ID, sign in as one user and request another user's record.
- Trigger an error in production and confirm no stack trace comes back. Change every default credential.
- Commit the lockfile, deploy with
npm ci, and runnpm audit. - Search the repository for keys, and confirm passwords use Argon2 or scrypt.
- Search for queries and shell commands built from strings, and parameterize them.
- Put a rate limit and a spending cap on anything that costs you money per call.
- Rate-limit login, expire sessions, and verify every token.
- Stop trusting values the browser sends back: sign them or look them up server-side.
- Log failed logins and 403 responses, and set one alert.
- Read every
catchblock on your auth and payment paths and make each one fail closed.
Scanning for this before you ship
For a solo dev, the practical move is to turn "OWASP Top 10" into a list of specific lines in your code instead of an abstraction. You can do that by hand with the ten steps above. If you would rather have something read your source first, the free IOnclad browser scanner runs a 167-rule subset entirely in your browser, with no signup. Your code stays in the tab.
The IOnclad desktop app runs 24 scanners and 500+ checks and returns one Ship-It verdict with the file, line and a fix for each finding. It does not promise your app is secure, and no scanner honestly can. If you are choosing between tools, see how IOnclad compares with Snyk, Semgrep and Trivy, and for the individual topics, browse the app security guides.