The Most Common Web Application and API Vulnerabilities Found During Penetration Testing

Web applications remain by far the most common type of project. In 2025, we performed 345 web application penetration tests, accounting for approximately 55% of all engagements. They also produced the highest number of findings: 1,347 vulnerabilities, including 63 critical and 119 high-severity vulnerabilities.

However, the average number of findings per project was lower than for infrastructure or cloud environments, at approximately 3.9. Web applications therefore accounted for the largest overall volume of findings, but with a lower average severity.

The most common issues are inadequate access control (Broken Access Control), injection vulnerabilities and authentication flaws. This is also confirmed by the updated OWASP Top 10:2025. Broken Access Control remains in first place and now also includes SSRF attacks.

What does this look like in practice? During a penetration test of a customer-facing web application, all we had to do was change a single number in the URL – the order identifier. Instead of the logged-in user’s order, the application displayed another customer’s order, including their name, address and purchased items.

No exploit or special tool was required. The application simply failed to verify whether the authenticated user was authorised to access the requested object. This is Broken Access Control in practice and the most common critical vulnerability we find in web applications.

However, 2025 also brought a new insight: the framework itself can become a vulnerability. React2Shell (CVE-2025-55182), a deserialisation flaw affecting React Server Components and Next.js, received the maximum CVSS score of 10.0. Attackers began exploiting it only days after disclosure, and it was added to the CISA KEV catalogue in December.

We are seeing the same shift in our penetration tests. Increasingly, we gain access not through a flaw in the application itself, but through its surrounding components: an exposed API key in a repository, a forgotten test account or a vulnerable third-party library. The application may be well written, but it trusts a component that is not.

If a company works with hundreds of suppliers, auditing every one of them is not realistic. A more practical approach is to require up-to-date security reports, use short-lived credentials with regular rotation, and continuously monitor which systems and data each integration can actually access.

API vulnerabilities: less visible, but even more dangerous

Across 48 API projects, we identified 145 findings, averaging three vulnerabilities per project. The dominant risk has remained unchanged for years: Broken Object Level Authorisation (BOLA) continues to rank first in the OWASP API Security Top 10.

It is the same flaw as in the example above, only one level deeper. While the user interface may not display another user’s object, the underlying API will readily return it when called directly. Although 99% of organisations have experienced at least one API security incident, according to Salt Security, few can accurately inventory all the APIs they operate.

What does this mean for CISOs?

Web applications represent a mature but constantly evolving attack surface where continuous testing delivers more value than one-off, in-depth audits. For APIs, one simple rule applies: you cannot protect what you do not know exists.

It is therefore worth investing in API discovery, object-level authorisation and server-side security controls.