The Open Worldwide Application Security Project (OWASP) periodically publishes the Top 10, a consensus ranking of the most critical web application security risks based on real-world breach and testing data. It is the closest thing web security has to a shared curriculum, and auditors, clients and job interviews all assume you know it. This lesson walks through the categories from the 2021 edition, which remains the reference list, with the mindset and defenses behind each.
The number one risk. Authentication asks 'who are you?'; access control asks 'are you allowed to do this?'. Failures include insecure direct object references (changing /orders/1001 to /orders/1002 and seeing someone else's order), missing function-level checks on admin endpoints, and privilege escalation. Defense: deny by default, enforce checks server-side on every request, and write tests that verify user A cannot touch user B's data.
// Access control: verify ownership on every request
app.get('/orders/:id', requireAuth, async (req, res) => {
const order = await db.orders.findById(req.params.id);
if (!order || order.userId !== req.user.id) {
return res.status(404).json({ error: 'Not found' }); // don't reveal existence
}
res.json(order);
});Sensitive data stored or transmitted without proper protection: plaintext passwords, deprecated algorithms, missing HTTPS, hardcoded keys. Defense: classify your data, encrypt in transit and at rest, hash passwords with bcrypt or Argon2, and use vetted libraries with modern defaults.
SQL, NoSQL, OS command and LDAP injection, plus XSS in this edition. One cause: untrusted input interpreted as code. Defense: parameterized queries, output encoding, and never passing user input to shells or eval. Lessons 6 and 7 covered these in depth.
Flaws baked into the architecture itself, such as a password recovery flow based on guessable questions. Defense: threat modeling before coding, abuse-case thinking ('how would I cheat this feature?'), and security requirements treated like functional ones.
Default credentials, directory listings, verbose stack traces in production, unnecessary features enabled, missing security headers. Defense: hardened, repeatable configuration through infrastructure as code, minimal installs, and automated configuration scanning.
Your app inherits every vulnerability in its dependency tree. Defense: keep an inventory (SBOM), run npm audit, Dependabot or similar continuously, patch promptly, and remove unused dependencies.
Weak passwords allowed, missing MFA, broken session management, credential stuffing not mitigated. Defense: everything from Lesson 3, plus secure session handling and login rate limiting.
Trusting updates, plugins or CI/CD artifacts without verifying integrity; insecure deserialization sits here too. Defense: signed packages, locked dependency versions with integrity hashes, protected build pipelines, and never deserializing untrusted data with unsafe formats.
Breaches routinely go undetected for months because nothing was watching. Defense: log logins, failures and privilege changes with timestamps and identities; centralize logs; alert on anomalies; rehearse how you would detect a breach.
The server is tricked into fetching a URL supplied by the attacker, potentially reaching internal services or cloud metadata endpoints that outsiders cannot. Defense: allowlist permitted destinations, block private IP ranges for user-supplied URLs, and isolate fetching services with minimal network access.
The list is a floor, not a ceiling: passing all ten categories does not make an app secure, but failing any of them makes it insecure. Use it to structure code reviews, as a checklist in design discussions, and as a shared vocabulary with security teams.
Next lesson: Secure Coding Practices for Developers, turning these risk categories into daily habits.