The OWASP Top 10 is the industry's shared vocabulary for web application risk. Every Oriole Security web application test covers all ten categories, and every finding in our reports is mapped back to one of them so your developers know exactly which class of bug they are dealing with.
A01 — Broken access control
The single most common serious finding we report. It looks like changing /invoice/1042 to /invoice/1041 and seeing another company's data, or calling an admin API as a normal user because the check lives in the UI instead of the server.
Fix: deny by default, enforce authorisation server-side on every request, and check ownership of the object, not just that someone is logged in. Test it with two accounts of the same role.
A02 — Cryptographic failures
Sensitive data in transit or at rest without adequate protection: missing HSTS, TLS 1.0/1.1 still enabled, passwords hashed with MD5 or SHA-1, card or NID data stored in plain text, secrets in source control.
Fix: TLS 1.2+ only with HSTS, Argon2id or bcrypt for passwords, encrypt sensitive fields at rest, and keep keys in a secrets manager.
A03 — Injection
SQL, NoSQL, OS command, LDAP and template injection. Still present, still devastating, and still caused by string concatenation.
Fix: parameterised queries everywhere, allow-list validation, and an ORM used the way it was designed. Escaping on output prevents cross-site scripting, which OWASP now folds into this category.
A04 — Insecure design
Flaws no amount of clean code will fix: a password reset that emails the token to an address the attacker controls, a checkout that trusts a price sent by the browser, a rate limit that does not exist because nobody thought about abuse.
Fix: threat model before you build. Ask "how would I abuse this?" for every new flow.
A05 — Security misconfiguration
Default credentials, directory listing enabled, verbose error pages exposing stack traces and database names, admin panels reachable from the internet, missing security headers, an S3 bucket left public.
Fix: hardened build images, configuration as code so environments cannot drift, and a repeatable hardening checklist per environment.
A06 — Vulnerable and outdated components
The framework version that shipped two years ago, the abandoned jQuery plugin, the container base image nobody has rebuilt.
Fix: a software bill of materials, dependency scanning in CI that fails the build on known-critical CVEs, and a patch SLA you actually meet.
A07 — Identification and authentication failures
Credential stuffing with no rate limiting, session IDs that survive logout, tokens that never expire, MFA that can be skipped by hitting the next URL directly.
Fix: MFA, rate limiting and lockout, rotate the session ID on login, short-lived tokens, and check passwords against known-breached lists.
A08 — Software and data integrity failures
Unsigned updates, CI/CD pipelines anyone can modify, deserialisation of untrusted data, third-party scripts loaded from a CDN without integrity checks.
Fix: signed artefacts, locked-down pipeline permissions, subresource integrity on external scripts, and never deserialise data you did not sign.
A09 — Security logging and monitoring failures
The reason breaches run for months. If failed logins, privilege changes and data exports are not logged — and nobody is watching the logs — you find out from your customers.
Fix: log security events with enough context to investigate, ship them off the host, alert on the patterns that matter, and have a SOC or on-call rota that responds.
A10 — Server-side request forgery (SSRF)
Your server fetches a URL the user supplied, and the attacker points it at internal services or the cloud metadata endpoint to steal credentials.
Fix: allow-list destinations, block requests to internal ranges and link-local addresses, and disable unneeded URL schemes.
The Top 10 is a floor, not a ceiling. Business-logic flaws unique to your application — the ones no scanner has ever heard of — are where a manual tester earns their fee.
Every Oriole Security web application penetration test maps findings to these categories, with reproduction steps and a specific remediation for your stack. Talk to our team about testing your application.