6 posts tagged with "API Security"

Proof of exploitability, or it didn't happen​

One of the most pervasive problems in cybersecurity is false positives. Organisations receive dozens of bogus vulnerability reports about their websites every day, and security teams burn hours trudging through the noise that automated scanners generate. Worse, CISOs can't prioritise what actually matters, because a false positive is so often hard to tell apart from a real finding.

How did we go so wrong? The ingredient missing from a false positive is proof of exploitability, and a rigorous one at that. Proof of exploitability, also called chain-of-attack proof, is one of the most important elements of any vulnerability report. Without it, a penetration testing report isn't worth your money. Reliable bug bounty platforms like HackerOne place heavy emphasis on proving a vulnerability is exploitable; without that ingredient, a report simply doesn't have a case.

A security scanner reports: 3,148 authorization requests are missing PKCE.

…and suddenly that sounds like 3,148 vulnerabilities. Or is it?

In March 2012, Egor Homakov performed one of the most famous exploits in application security history: he acquired write rights to Ruby on Rails's GitHub repository and committed directly to its master branch. The commit is still visible for all to see (here). How was Homakov able to do this? He exploited a vulnerability in GitHub's API that allowed him to overwrite arbitrary server-side properties. Specifically, he bound his own SSH key to the profile of another user with commit rights to Ruby on Rails's repository.

Sign in with Google, the signature verifies, and the token is valid. PKCE checks out, the redirect_uri matched exactly, state came back untouched. Textbook flow, start to finish. Then the application runs find_user_by_email(claims.email), and the session goes to whoever controls that address.

Ten of the OAuth and OIDC vulnerability reports we read end that way. In none of them did the protocol fail. It ran perfectly and handed over the account anyway.

Your API has a bouncer. Very professional. Checks every ID at the door. Unfortunately, once you're inside, you can walk into the kitchen, rearrange everything, and delete someone else's reservation and he's still at the front door, extremely proud of himself.

Most security teams know what BOLA is. Broken Object Level Authorization, the vulnerability where an API doesn't verify that you're allowed to access the specific object you're referencing, not just the endpoint. It has sat at the top of the OWASP API Security Top 10 since 2019. There are guides, courses, and CTF challenges built around it.

And yet we analyzed over 100 validated, publicly disclosed bug bounty reports from HackerOne spanning 2021 to 2026, across 29 organizations including GitHub, GitLab, Shopify, Mozilla, and more, and found something that should give every security team pause.

The way most teams are testing for BOLA doesn't match how BOLA actually shows up in the wild. Here's what the data says.

First, a Quick Note on the Tag Noise​

One number worth flagging: roughly 39% of reports tagged IDOR or Improper Access Control on HackerOne don't describe BOLA under rigorous criteria. Wrong vulnerability class entirely, auth bypass without object reference, business logic on a user's own resources. If your team is using platform tag-counts to estimate BOLA exposure, you're likely overstating the signal significantly. Hence, these were excluded under the prefilter criteria of our research.

Finally, the 84 confirmed, in-scope reports are what everything below is drawn from. The full dataset, classification methodology, and analysis scripts are available on GitHub.

Modern e-commerce platforms increasingly rely on distributed API architectures to power web and mobile applications. But as architectures shift toward interconnected microservices, the most dangerous bugs are found in the way data flows in the applications.

Recently, we conducted a structured security evaluation of a large-scale e-commerce API ecosystem. Rather than focusing on isolated vulnerabilities, the research aims to identify systemic patterns of failure across authentication flows, parameter handling, and microservice interactions.

Our mission: to see if we could break the business rules of a production environment using nothing but an interception proxy and a bit of creative curiosity.