Dit artikel is alleen in het Engels beschikbaar.
The OWASP Top 10 maps where web and API risk lives; it is not a scanner report or a scoring system, but a set of categories a tester keeps in mind while working through an application by hand. This post covers the categories that show up most often in real assessments, with a plain example and the fix. The examples are illustrative, not drawn from any client.
A scanner can flag a missing header or an outdated library. It cannot reason about whether one user can reach another user’s data, which is the most common serious finding in modern applications. That reasoning is manual work.
Broken access control
This category produces the most high-severity findings, and it is almost always found by hand. The application authenticates a user, then fails to check that the user is allowed to see the specific record they asked for.
A request for /api/invoices/1041 returns an invoice. Changing it to 1042 returns another customer’s invoice, because the server checks that the caller is logged in but not that the invoice belongs to them. The same pattern hides admin functions that any account can still reach.
The fix is to enforce authorisation on the server for every request, based on who is calling and what they own, not on what the interface chooses to show. Access control tested only through the user interface is not tested at all.
Injection
Injection is older than the Top 10 and it has not left. SQL injection is rarer now that parameterised queries are the default, but it still appears where a query was built by hand. It also lives in operating system commands, LDAP filters, and template engines.
GET /search?q=widget' OR '1'='1 HTTP/1.1
Host: example.internal
That is the classic probe. The real cases are subtler, such as a sort parameter that reaches the database without validation. The fix is constant: never build a query or command by joining strings with user input; use parameterised queries and safe APIs, and compare structural values such as a sort column against an allowed list.
Security misconfiguration
This is the broadest category, and a thorough assessment always turns it up. It covers default credentials, verbose error pages that leak stack traces, admin interfaces exposed to the internet, permissive cross-origin rules, and readable cloud storage.
Most misconfigurations are not subtle; they are a default that was never changed, or a debug setting that reached production.
The fix is process as much as code: ship a hardened baseline, keep debugging and verbose errors off in production, and build every environment the same way so a fix in one place holds everywhere.
Server-side request forgery
Server-side request forgery, or SSRF, has become more serious in the cloud. The application takes a URL from the user, for a webhook or an image preview, and fetches it from the server. If that request can be pointed at an internal address, the server becomes a proxy into the internal network, or into the cloud metadata service that holds credentials.
The fix is to treat any user-supplied URL as hostile: validate it against an allowed list, block internal and link-local addresses, and require the hardened metadata service so a single request cannot retrieve a credential.
The full list at a glance
The four above appear most often with real impact. The table covers the current OWASP Top 10 in full.
| Category | What to check |
|---|---|
| Broken access control | Can one user reach another user’s data or an admin function |
| Cryptographic failures | Is sensitive data protected in transit and at rest, with current algorithms |
| Injection | Is any user input reaching a query, command, or template unescaped |
| Insecure design | Are there missing controls that clean code alone cannot fix |
| Security misconfiguration | Defaults, verbose errors, exposed interfaces, permissive rules |
| Vulnerable components | Known-vulnerable libraries on a reachable code path |
| Authentication failures | Guessing protection, session handling, multi-factor coverage |
| Software and data integrity | Unverified updates, untrusted deserialisation, build pipeline trust |
| Logging and monitoring failures | Would an attack even be visible in the logs |
| Server-side request forgery | Can a user-supplied URL be pointed at internal services |
Closing
The Top 10 works best as a checklist for a human tester, not a scoring sheet for a scanner. Every finding should arrive with evidence, reproduction steps, and a clear fix.
For how a web and API assessment is structured, see the penetration testing service page.
