Some recent API security blunders and how they could have been avoided



This is the second of three blogs invited as part of our collaboration with Cequence. In the first blog post on August 30, I wrote about how we have seen the level of knowledge of API security increase since our initial research in 2019, but more needs to be done to secure the use of APIs in the world. today’s hyperconnected world. In this first blog post, I noticed that CISOs (especially in financial services organizations) and software developers have stepped up their API security game and saw a general increase in the security maturity of the APIs. API. Nonetheless, reported API security vulnerabilities and API security vulnerabilities continue to emerge every month. Therefore, more needs to be done.

Over the past 60 days, we’ve seen API vulnerabilities reported for Cisco’s networking equipment, Bumble’s dating app, Microsoft’s PowerApps platform, and Valve Software’s Steam portal. In the case of Microsoft’s PowerApps platform, cybersecurity firm UpGuard has linked the API’s vulnerability to the disclosure of 38 million records containing Personally Identifiable Information (PII). Security researchers reporting these vulnerabilities attributed the following causes:

  1. Cisco – Incorrect access control in an API that could lead an attacker to read or write to files – and ostensibly tamper with device firmware. Affected products included Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC). Details can be found in CVE-2021-1577. This came from a broken authentication, # 2 on the OWASP API’s Top 10 Security List.
  2. Bumble – A security researcher received a bug bounty of $ 2,000 for reporting a location-based vulnerability from a poorly designed API endpoint. The vulnerability could be exploited by an attacker to spoof their location and determine the precise location of a Bumble user without authorization. A separate API vulnerability could allow an attacker to access a user’s profile information without being in their stream. This was the result of a broken object-level authorization, # 1 on the OWASP API Security Top 10 list.
  3. Microsoft – An open data protocol API used by PowerApps had a default setting that disabled table permissions and made data publicly available. The root cause was attributed to a broken authentication, # 2 on the OWASP API Security Top 10 list.
  4. Valve Software – A vulnerability in the Steam Wallet API created a situation where a user could add value to their account by modifying user input. The input schema was protected by a hash function, but the implementation was flawed. The vulnerability was attributed to improper application of payload patterns and reported a bug bounty of $ 7,500 to Valve.

All right, let’s just clarify that despite improvements in API security maturity, building and implementing APIs is complex and remains a challenge for many organizations and development teams. Additionally, security teams often lack tools to test APIs to find these vulnerabilities. But in the case of the first three examples, the OWASP API Top 10 has detailed descriptions and recommendations to help developers avoid these authorization and authentication issues. Valve Software’s vulnerability is a bit more complex but could have been avoided through secure coding practices.

To be clear, simple awareness and superficial testing is not enough to avoid these security holes. API security maturity encompasses many other factors, including designating a point of contact for API security, maintaining an inventory of internal and external APIs, and publishing an API catalog or an API development portal to help internal or external developers implement the API.

Specifically, creating an API specification for each API using a standard such as OpenAPI or API Blueprint will define how the API works and how it relates to data sources and other APIs. Through the development of the specification, it is possible to uncover potential gaps in authentication and authorization. Developing specifications can also lead to a threat modeling exercise with security professionals to determine “… so what’s the worst that can happen?” “

Now is the time to jumpstart or double your API Security Improvement Program. I will cover other aspects and recommendations in the upcoming third blog and a joint webinar with Cequence “Shielding Right to Strengthen Shift Left: Here’s How” on October 6th.e.

Joseph has been a cybersecurity analyst since 2019. He has worked in the information security field for over 45 years. His previous roles include as operations officer for the US intelligence community, CISO at large publicly traded companies, and cybersecurity strategy consultant for Accenture and PwC. He has worked in 115 countries and has a keen interest in disruptive and emerging cybersecurity technologies.

The article Some recent API security blunders and how they could have been avoided appeared first on Cequence.

*** This is a syndicated Security Bloggers Network blog from Cequence written by Joseph Krull. Read the original post at:



About Author

Leave A Reply