When we started 42Crunch 3 years ago, we were convinced that a new market segment would emerge: API security. And the market is now catching up with our vision!<\/p>\n
This is exemplified by the recent release of the OWASP Top 10 for API Security<\/a> threats document, which highlights threats that do not apply to traditional web applications. In other words, if your security products protect you against the traditional OWASP Top 10, they probably don’t properly protect your API traffic.<\/p>\n We have confirmed this problem with many of our prospects, who thought that by configuring their existing WAFs, they would be able to protect their APIs, complementing the authentication and authorization mechanisms provided by their API Management solutions. In most cases, the result has been far from satisfactory: the WAFs configuration ended up being very complex to put in place, triggered many false positives, and forced customers to fall back to generic rules that just caught the obvious issues (like injections).<\/p>\n As noted in the Gartner’s Hype Cycle for Application Security, 2019:<\/p>\n “Leading cloud WAF vendors are adding features, moving closer to a more comprehensive web application and API protection (WAAP) solutions. However, API protection continues to be very basic, sometimes limited to applying the same signatures rather <\/em>than for protecting more traditional web applications.”<\/em><\/p><\/blockquote>\n The report then adds:<\/p>\n “Mobile applications and the growing number of publicly exposed APIs create new development opportunities for WAFs. <\/em>Gartner observes, though, that innovation continues to happen mostly outside of the traditional WAF vendor landscape.”<\/em><\/p><\/blockquote>\n Indeed, we feel protecting APIs needs a new approach. As the OWASP Top 10 for API Security document highlights, API threats are a superset of Web application threats. While injection-based issues are common to both types of traffic, APIs suffer from critical issues related to resources access and data access or exfiltration.<\/p>\n An example would be a vulnerability where the first problem is that the API returns all<\/strong> the resource information as a JSON object, relying on the client application to filter the information at the UI level. This call now exposes critical information, easily accessible via a web proxy. This problem can be further exploited if the API also allows to update the information via a “hidden” POST call, allowing a hacker to credit their user account without ever making a payment.<\/p>\n Protecting yourself from such attacks implies limiting requests and responses to the ones exposed by the API contract. You cannot create generic denylist rules for this. You need to rely on a positive data model whereby the API firewall knows what is allowed or not via the contract and can also validate who the user is (their role for example) before allowing access to a resource.<\/p>\n To address such a need, our auditing service ensures the quality of\u00a0your API contract, while our API firewall automatically enforces\u00a0what the API contract specifies.<\/p>\n But tools are not enough: in order for API security to work, it needs to be fully part of the API lifecycle.\u00a0We will detail in an upcoming blog why a DevSecOps approach<\/a> is critical to API security!<\/p>\n <\/p>\n Try our security audit<\/a> for free. If you want to see the whole platform in action, request a demo now<\/a>!<\/p>\n