OWASP Top 10 (2021) — a short guide for developers

The OWASP Top 10 is a list of the most important risk categories for web applications. It is produced by the OWASP community and updated from time to time. Findings in cybersecurity expertise reports are often mapped to these categories, so for a developer, knowing the list means understanding the language of the expertise.

The list describes categories of weaknesses rather than specific bug types; each category covers dozens of CWE entries. So the point is not to memorize it but to apply it to your own project: for each item, ask "where could this exist in our system?"

Below is a short take on each item of the 2021 edition: what it is and what you can check today.

A01. Broken Access Control

A user can reach data or actions that don't belong to them. The classic example: change /invoices/1042 to /invoices/1043 and see another customer's invoice (IDOR).

Check: does every controller verify on the server that the object belongs to the current user? In Laravel, that's what Policies and authorize() are for. Hiding a button in the UI is not protection.

A02. Cryptographic Failures

Sensitive data transmitted or stored in the clear or with weak protection: login over HTTP, passwords hashed with MD5, unencrypted backups.

Check: is the whole site on HTTPS with HSTS enabled; are passwords hashed with bcrypt or argon2; are old TLS 1.0/1.1 disabled?

A03. Injection

User input goes straight into a query or command: SQL, OS commands, and also XSS (the 2021 edition folds XSS into this category).

Check: is there DB::raw() or string concatenation in raw SQL; is there unescaped output in templates ({!! !!}, dangerouslySetInnerHTML)? Parameterized queries and default escaping are the main defence.

A04. Insecure Design

The code is written correctly, but the process itself is poorly thought through. The expertise of our own product had exactly this kind of finding: the "payment successful" page was shown before the provider confirmed the payment, and some actions could be performed without the required state check.

Check: does every flow that changes state (payment, approval, cancellation) behave like a state machine on the server? Payment status should change only based on the provider's confirmation request (callback/webhook).

A05. Security Misconfiguration

Debug mode on, default passwords, unnecessary open ports, missing headers, trusting unverified proxy headers. In our experience several findings fell into this category: FTP and panel ports open to the internet, trusting X-Forwarded-Host (host header injection), and sending the full route list to the browser.

Check: APP_DEBUG=false, open ports via nmap, security headers, admin panel reachable only through an IP allowlist.

A06. Vulnerable and Outdated Components

A library, framework or server software with a known vulnerability.

Check:

composer audit
npm audit --omit=dev

Also keep an eye on nginx, PHP and database versions.

A07. Identification and Authentication Failures

No limit on password guessing, sessions not invalidated on logout, password reset tokens reusable or valid for too long.

Check: is there rate limiting on login and password reset; is the session ID regenerated after login; do cookies carry Secure, HttpOnly and SameSite?

A08. Software and Data Integrity Failures

Pulling code or data from an unverified source: a CDN script without an integrity attribute, unsigned updates, deserializing untrusted data.

Check: Subresource Integrity on external scripts (integrity="sha384-..."); is unserialize() ever applied to user data; who can push changes into CI/CD?

A09. Security Logging and Monitoring Failures

Even when an attack happens, nobody knows: failed logins, denied requests and admin actions are not recorded.

Check: are important events logged; are passwords and tokens kept out of logs; does anyone read the logs, or are alerts configured?

A10. Server-Side Request Forgery (SSRF)

The server sends a request to a URL supplied by the user, and the attacker points it at internal services (for example 127.0.0.1 or a cloud metadata address).

Check: do you have features like "upload image from URL" or webhook URLs? If so, are destinations restricted by an allowlist and are internal IP ranges blocked?

The OWASP Top 10 is not a complete testing standard but an awareness document. For deeper testing, the OWASP ASVS requirements are used.

Using the list in practice

1. Tie each item to concrete places in your project: which controller, which setting, which flow.
2. Automated tools (dependency audit, header scanner, port scanner) quickly cover A02, A05 and A06.
3. A01, A04 and A07 need manual review — a scanner doesn't understand business logic.
4. Record every issue you find with its CWE identifier: it makes matching your findings against the expertise report much easier.

Summary

The OWASP Top 10 gives developers a shared language for talking about risk. Use it as a short checklist before every release, and a large share of the typical issues the expertise finds will be closed ahead of time.

Want a quick look at your project against the OWASP Top 10? Request a security scan — the Claude AI agent and our specialist will show you where you stand across the main categories.