OWASP Top 10: The Vulnerabilities We Actually Find in Audits

Why the same mistakes keep happening

The OWASP Top 10 has been documenting the most critical web application vulnerabilities for over twenty years. It gets updated, publicized, studied… and yet, when we audit an application, we run into the same families of flaws over and over again. Not because teams are bad, but because security degrades by default: if nobody actively works on it, every sprint erodes it a little.

This article is not the official OWASP list — you'll find that at owasp.org — but what actually shows up in our audits, how to detect it early, and what to do about it.

The vulnerabilities we find in almost every audit

1. Broken access control (the undisputed champion)

It's number one on the OWASP list and number one on ours too. The typical pattern: the application checks that you're authenticated, but not that the resource is yours. Changing /invoices/1024 to /invoices/1023 and seeing another customer's invoice is the classic that still shows up in mature applications. It's called IDOR and it's fixed by verifying resource ownership on the server, on every request — not just in the interface.

2. Poorly managed sessions and authentication

Tokens that never expire, sessions that survive a password change, "log out" buttons that invalidate nothing on the server, and APIs that accept credentials in the URL (where they end up recorded in logs and proxies). Authentication is usually fine the day it's implemented; the problem is everything that gets built around it afterwards.

3. Injection: alive and kicking

SQL, commands, templates… In 2026, injection still shows up, mostly in "peripheral" code: legacy endpoints, reports, advanced search, internal integrations. ORMs protect you on the happy path, but a single hand-built query in a forgotten corner is all it takes.

4. Sensitive data exposure

Errors that return full stack traces to the user, API responses that serialize the entire object (with fields the UI never shows but the JSON does), logs containing personal data or credentials, and backup files publicly accessible. Data leaks are rarely a sophisticated attack: they're usually an overly generous response.

5. Insecure configuration

Missing security headers, CORS open to any origin, exposed admin panels, accidentally public storage buckets, debug mode in production. It's the easiest category to detect and to fix, and one of the most common.

6. Vulnerable dependencies

The modern application is 80% third-party code. Libraries with vulnerabilities published months ago, container images that never get rebuilt, abandoned packages nobody watches. Without a continuous update process, the dependency inventory becomes a silent time bomb.

7. Secrets in the code

API keys, passwords, and certificates in the repository — sometimes in the latest commit, sometimes buried in the history (where they still are). Anyone with access to the repo, present or past, has them. The rule is simple: secrets live in a secrets manager or in the environment, never in git.

Warning signs you can check without being technical

Does changing a number in the URL let you see another user's data? (Don't test this on someone else's production; ask your team whether ownership is verified on the server.)
Do application errors show technical details (stack traces, SQL, file paths)?
Are service passwords in a shared document or in the code?
When were the project's dependencies last updated? Is there a process for it?
Does logging out on one device actually log out everywhere?

If any of these answers makes you uncomfortable, there's work to do.

What is NOT enough

Let's be clear: having a WAF in front doesn't fix broken access control (it just disguises it until someone finds the way through), the server antivirus doesn't see application vulnerabilities, and "we ran a scanner a year ago" is not a security program — it's a snapshot. Automated tools find a portion — the easy one; business logic vulnerabilities, which are the most damaging, are only found by an expert review.

What a well-done security audit looks like

A serious audit combines three layers: automated analysis (dependencies, configuration, exposed surface), manual review of code and access logic (where the flaws that matter live), and testing against the running application. The result should not be a 200-finding PDF without context, but a prioritized list: what's critical, what's urgent, what's improvable — and how to fix each item with an estimated effort.

How long since someone looked at your application with an attacker's eyes?

If your application handles customer data, payments, or sensitive information, the question isn't whether it has vulnerabilities, but which ones and how many. Our security audits give you the real picture — code, configuration, and dependencies — with a prioritized remediation plan your team can execute from day one. Let's talk about your application.