{"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 APIs must not be treated like applications and are subject to a different range of attacks and vulnerabilities as identified by the <\/span>OWASP API Top 10<\/span><\/a>. Many of the breaches I examined were attributable to one of these Top 10 attacks, and many others besides. You can learn more about the minutiae of some of the more common OWASP API security risks<\/a> in this <\/span>recent webinar <\/span>from 42Crunch. So an important starting point is to dissect what particular vulnerabilities you have been exposed to, in order that you can remediate against them.<\/span><\/p>\n OpenAPI Specification – Declare, Test and Scan<\/b><\/p>\n The fastest route to identifying the faults usually lies by consulting with the development team that built the API in order to analyze the associated OpenAPI Specification (OAS) or Swagger file that defines how the API should operate. Leveraging the declarative nature of the OAS file in combination with 42Crunch\u2019s API-specific testing tools (API Audit – static testing of the API and API Scan – dynamic testing of the API) you can quickly assess the Data Validation and Security Conformance of the vulnerable API.\u00a0<\/span><\/p>\n Proof and Implement<\/b><\/p>\n\n