{"id":18505,"date":"2024-03-21T19:25:28","date_gmt":"2024-03-21T19:25:28","guid":{"rendered":"https:\/\/staging2022.42crunch.com\/?p=18505"},"modified":"2024-03-25T17:36:19","modified_gmt":"2024-03-25T17:36:19","slug":"so-your-api-has-been-breached-now-what","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/so-your-api-has-been-breached-now-what\/","title":{"rendered":"So, your API has been Breached, Now What?"},"content":{"rendered":"

Last week I had the privilege of presenting some real-world API security case studies at the annual <\/span>API Summit in Austin<\/span><\/a>, Texas. On foot of several requests, I have summarized in this post some of the key steps an enterprise should undertake, once they discover that their API has been compromised. \"\"<\/span><\/p>\n

Dissecting the API Security Problem<\/b><\/p>\n

The root cause of many API security breaches has been a common misconception made by security teams that<\/span> existing investments in Web application firewalls and Static and Dynamic application testing solutions mean that their APIs are protected. Wrong! <\/span>The <\/span>traditional web application firewall<\/span><\/a> (WAF) and <\/span>security code testing solutions<\/span><\/a> are not up to the task of finding the API vulnerabilities:\u00a0<\/span><\/p>\n