Whitepaper

Q2-2022 API Vulnerability & Exploit full report

In Q2-2022, the Wallarm Research team found 184 API-related vulnerabilities out of a total of 88,241 records examined, an increase of +268% over Q1.

This research over the last two quarters shows that the volume of API vulnerabilities has more than doubled and time to exploit has halved. Check out the results in this report and learn why you need to set data defensible remediation policies that engineers and executives will support – particularly as API vulnerabilities continue on their exponential growth trajectory through 2022.

Thanks for filling out the form!

The resource link will open in the new tab. If its not, please follow this link

Oops! Something went wrong while submitting the form.

Key Take-Aways

Based on this analysis of Q2-2022 API vulnerabilities and the trends we’ve seen over H1-2022, we recommend you consider the following when assessing your API security:

Growth Rate. API-specific vulnerabilities reported in Q2 grew by 268% to 184 total (or about2 per day) – which suggests an ever-increasing risk in your API portfolio.

Criticality. The number of Critical and High risk API vulnerabilities remain dramatically high, in the 60% range – which also indicates that extra vigilance is needed.

Attack Vectors. Injections (OWASP A03 / API8) are now the highest risk for APIs, ahead of BOLA by all metrics (number of issues discovered, exploitability, and severity) – which points to the need for more pre-release testing.

Depth & Breadth. Concurrently we’re seeing more “most dangerous” CWEs being found with broader (more vendors, more products) and deeper (e.g., attacks against Dev Tools) impact– which emphasizes the need.

Exploitability. 33% of the API vulnerabilities reported in Q2 were almost immediately exploited, with POCs published within a median of 2-1/2 weeks – since these exploits are probably underreported, this illustrates the need for run-time protection.

Impartiality. Open Source software is not necessarily less vulnerable than commercial software, and the nature of the vulnerabilities in them differ – which means that neither should be treated as special when it comes to vulnerability management.