Akamai acquires Neosec

In the first post of our blog series on API threat hunting, we explored the technology shifts that are making API threat hunting an essential priority for security leaders. We then followed this up with a real-world example from Uber of how multiple undiscovered API vulnerabilities can be combined with potentially devastating impact.

It can be tempting to view high-profile incidents like the one at Uber as a “perfect storm”. But as APIs assume a more central role in your business, finding and mitigating these types of API vulnerabilities must be a core element of your security program.

To illustrate the point, we’ll explore a lesser known example of how a similar technique of stacking multiple API vulnerabilities opened the door to sensitive data exfiltration at the German education application firm Scoolio.


Incident Snapshot
Attack Summary Vulnerabilities Exploited:

Outcome of Attack:
Massive Data Exposure

Industry: Education

Vulnerabilities Exploited:

  1. Broken Object Level Authorization
  2. Broken User Authentication
  3. Excessive data exposure
  4. Lack of resources and rate-limiting
  5. Broken Function Level Authorization
  6. Mass assignment
  7. Security misconfiguration
  8. Injection
  9. Improper assets management
  10. Insufficient logging and monitoring


The Scoolio app collects extensive information from its student users. For example, it conducts personality tests, provides social networking and chat features, and manages activities like study planning and tutoring. These features amass a trove of personally identifiable information (PII).

Security researcher Lilith Wittmann discovered a BOLA vulnerability in Scoolio’s APIs in 2021 that made it possible to utilize two API calls to access PII and other data for any other user of the Scoolio app.

For a brief overview of how the exploit worked, check out this excerpt from our recent webinar, “API Threat Hunting: Anatomy of an API Attack.”


HubSpot Video

Click here to watch the complete webinar replay.

In the example, you see some of the same techniques from our last post on Uber repeated, such as excessive data exposure giving an external party the ingredients needed to execute a BOLA attack. But in this case, there was also a third example of how an OWASP API Top 10 item can appear in a real-world environment.


Improper asset management

One particularly notable element of Scoolio API vulnerability exploit is that it took advantage of improper asset management, which is number 9 (API9:2019) on the OWASP API Top 10 list. If you paid close attention to the attack sequence described in the video excerpt above, you may have noticed that the first step is applied to version 3 of the API, while the second step was taken against version 2. Improvements were made in version 3 that more tightly governed access to PII. However, these improvements were undermined by the fact that the more vulnerable version 2 remained accessible to all. Ultimately, both version 2 and version 3 were affected by the BOLA vulnerability. But the unnecessary presence of version 2 made the impact of the vulnerability more severe.


A note about UUID usage

You may have noticed that in both the Scoolio incident and the Uber incident described in our last post, the attack technique used centered on discovering and using universally unique identifiers (UUIDs). But it’s important to note that this has more to do with these specific API implementations than any case to be made against the use of UUIDs. The use of UUIDs is in fact a very good practice. Using randomly generated numbers instead of a predictable sequence of user identifiers makes it more difficult for a threat actors to access information for users en masse. The problem arises when the UUID information is exposed too permissively and combined with BOLA vulnerabilities.


Key takeaway for Security Teams

Our intention in recounting the Uber and Scoolio API security incidents is not to disparage the companies affected. API vulnerabilities are a fact of life that affect all organizations that use APIs widely. Rather, our goal is to bring an important point to life: understanding API vulnerabilities conceptually isn’t enough. 

Your applications will only be protected if you have ways to map broad categories of API threats to specific aspects of your unique API implementation. Only this will give you the foundation you need to conduct proactive API threat hunting activities that reduce your ongoing risk.

In our next and final post of this series, we’ll share some practical tips and examples of how to do this in your environment and get your API threat hunting initiative off the ground.


In the meantime, we also encourage you to check out the full replay of the API threat hunting webinar excerpted above.



Additional Reading in our API Threat Hunting Series:



API Security: Debunking the Myths

Learn the fundamentals of API security. Made for security leaders and practitioners to increase their foundational knowledge about API security and best practices.


Gartner provides a view into API trends. Learn More.