The vulnerabilities that recur most in real penetration tests, in rough order of impact: broken access control (esp. object-level authorisation - the #1 in OWASP and the API Top 10), business-logic abuse, weak authentication & session handling, security misconfiguration, injection, and exposed secrets / excessive data exposure. The through-line: the highest-impact findings are logic and authorisation flaws a scanner cannot find, because only your app knows who should access what. This is a field pattern, not a formal study - we won't dress opinion as a statistic. The durable fix is root cause, not per-instance. Details below.
// 01 A note on honesty
You'll find plenty of vendor posts citing precise figures - “73% of apps have X.” We're not going to invent one. What we can tell you truthfully is the pattern that recurs across GCC web and API engagements, and how closely it tracks the OWASP Top 10 and API Security Top 10 - which are backed by large datasets. So treat this as a practitioner's field view: the categories are real and consistent; we simply won't attach a fake percentage to them. That honesty is itself the point of the piece - if a provider's “statistics” can't be sourced, be sceptical, exactly as you should be of a report full of unsourced claims.
// 02 Broken access control - the perennial #1
Nothing shows up more, or hurts more, than broken access control. It leads both the OWASP Top 10 and the API Security Top 10, and it's the finding we most often escalate. The worst form is broken object-level authorisation (BOLA/IDOR): the app returns a record based on an ID without checking it belongs to the caller, so changing the ID reads or edits other users' data - a mass breach from a one-character change. Close behind is function-level authorisation: ordinary users invoking admin endpoints. It's perennial because it depends on application-specific logic developers must get right on every endpoint, and it's invisible to scanners because only the application knows who should access what.
// 03 The rest of the recurring cast
Business logic abuse
Manipulating intended workflows - pricing, discounts, limits, points - for gain. No “bug” per request; the flaw is the flow.
Weak auth & sessions
Flawed session handling, weak tokens, and OAuth/SSO integration mistakes that enable takeover.
Misconfiguration
Missing hardening, verbose errors, permissive CORS, default settings - especially in cloud.
Rounding out the list: exposed secrets (API keys and credentials in code, configs or client-side) and excessive data exposure through over-sharing APIs. None are exotic; all are common; several are critical when chained.
// 04 Why scanners miss the ones that matter
Here's the uncomfortable truth the pattern reveals: the flaws that cause breaches are largely the flaws scanners cannot find. Automated tools excel at known-vulnerable components, missing patches and signature-matchable issues - genuinely useful, and a fine input to a test. But broken access control, business-logic abuse and chained vulnerabilities require understanding the application's intended behaviour and privilege model, which a scanner has no concept of. A tool cannot know one user shouldn't see another's invoice, or that a discount shouldn't stack. That's not a tuning problem - it's structural. It's the entire case for manual, human-led testing, and it's why a report that's all CVEs is a red flag: it means nobody tested the things that actually get you breached.
// 05 Fixing the root cause, not the instance
The reason these categories recur is that teams often fix the instance a test found, not the root cause. The durable remedy is different for each class, but shares a shape: design the flaw out. For broken access control, enforce authorisation server-side on every object and function through a centralised, consistently-applied mechanism - not scattered per-endpoint checks that someone will forget. For business logic, threat-model the sensitive flows during design. For authentication and configuration, use proven frameworks with secure defaults and remove the ability to misconfigure. Combined with code review and regular testing, this turns the same recurring findings into designed-out risks - so next year's test finds new things, not the same things. That's the goal our methodology is built around.
// 06 Frequently asked questions
What is the most common vulnerability found in pentests?
Broken access control - consistently the most common and highest-impact category, leading both the OWASP Top 10 and API Security Top 10. The most damaging form is broken object-level authorisation, where the app doesn't check the user is allowed the specific record requested, so changing an identifier reads or edits others' data. It's common because it depends on app-specific logic on every endpoint, and invisible to scanners.
Why do scanners miss the important vulnerabilities?
Scanners match known signatures - good for vulnerable components, missing patches and some technical flaws. But the highest-impact findings (broken access control, business-logic abuse, chained vulnerabilities) depend on understanding the app's intended behaviour and privilege model, which a scanner has no concept of. It can't know one user shouldn't see another's invoice, so it can't test for it.
What are the most common vulnerabilities across web apps?
Broken access control (object and function-level), business-logic flaws, weak authentication and session management, security misconfiguration, injection in its various forms, and exposed secrets or excessive data exposure via APIs. These map closely to the OWASP Top 10 and API Security Top 10, and the pattern is stable across years and sectors.
How do you fix these for good?
Address the root cause, not each instance. For access control, enforce server-side authorisation on every object and function through a centralised mechanism. For business logic, threat-model sensitive flows in design. For auth and config, use proven frameworks with secure defaults. Combined with code review and regular testing, this shifts recurring findings into designed-out risks.