Positive Security for APIs: What it is and why you need it!
Many of the issues on the OWASP API Security Top 10 are triggered by the lack of input or output validation. Here are a few illustrative real-life examples on this:
- Drupal suffered a major issue in February 2019: a remote code execution flaw due to a parameter not properly validated.
- Tchap, the brand new messaging app of the French government was hacked in an hour due to the lack of validation of the registration email.
- CVE-2017-5638, better known as the “Equifax attack”. This vulnerability in Apache Struts could be exploited by crafting a custom Content-Type header and embedding ONGL expressions in the header value.
- Cisco got fined $8.6 million for knowingly selling its Video Surveillance Manager (VSM) product that included API vulnerabilities to the US federal and state agencies. The actual API flaws included a lack of user input validation and insufficient authentication.
To protect APIs from such issues, an API-native, positive security approach is required: we create an allowlist of the characteristics of allowed requests. These characteristics are used to validate input and output data for things like data type, min or max length, permitted characters, or valid values ranges. But how do we fill the gap between security and development mentioned above?
What you’ll learn:
- Why WAFs fail in protecting APIs
- How an allowlist protects against A3, A6 and A8 of the OWASP API Security Top 10 – (with real-life examples)
- How to build a proper allowlist for API security