{"id":16188,"date":"2023-03-15T09:00:20","date_gmt":"2023-03-15T09:00:20","guid":{"rendered":"https:\/\/staging2022.42crunch.com\/?p=16188"},"modified":"2023-03-15T14:36:15","modified_gmt":"2023-03-15T14:36:15","slug":"mind-the-gap-how-api-security-testing-tools-complement-api-gateways-for-enhanced-api-security","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/mind-the-gap-how-api-security-testing-tools-complement-api-gateways-for-enhanced-api-security\/","title":{"rendered":"Mind the Gap! How API Security Testing Tools Complement API Gateways for Enhanced API Security"},"content":{"rendered":"
\u201cI want security, yeah<\/em> Otis Redding may well have been singing about the love for another in these famous lines, but taken literally, his message will resonate with any company that has recently suffered an API breach. Sadly the number of companies impacted by API breaches is growing day by day. As noted in a recent market survey by Google, as much as 63% of C-suite executives reported an API security breach in the last 12 months. 1<\/sup><\/p>\n Examining these companies we can see a common architectural pattern. Despite all relevant Web Application security measures being in place, a Web Application Firewall (WAF) and an API Gateway at the edge for the runtime, plus the DAST\/SAST process and tools enabled to protect at implementation time, we are still witnessing a growing number of successful hacks exploiting API vulnerabilities.<\/p>\n Naturally enough you are wondering, what\u2019s missing? How can we do better?<\/p>\n Looking into the breaches in detail we can see that there is a very clear gap in these web AppSec programs that ignores securing the APIs at design time and is exposing companies to potential exploitation by hackers.<\/p>\n Let\u2019s take the Topcoder BOLA vulnerability as an example. 2<\/sup><\/p>\n In the example above we can see that the API involved in the communication has a vulnerability in the design and the implementation.<\/p>\n Just\u00a0like Topcoder, if you already have APIs in production you don\u2019t want to wait until an intelligence, human or artificial, discovers the vulnerability, or worse, you are alerted by a breach.<\/p>\n To avoid such problems occurring 42Crunch recommends companies use dedicated API security testing tools at design time, to examine the API definition, the OAS file, of each API to clean up the mess, prior to deployment. Furthermore, such tools will also enable you to restrict all PII data exposure to the absolute minimum as well as ensure that each parameter is not just \u201cstring\u201d.<\/p>\n In the Topcoder example, an\u00a0 audit of the OAS file would have pointed out that an identifier in the path is an integer, and not an UUID as per best practice.<\/p>\n Also make sure that no API Endpoint is without authentication and authorization.\u00a0Do this automatically for all APIs in your repositories and give the API Designer an educated feedback on what must be fixed.\u00a0Best case you take the OWASP API Top 10 vulnerabilities as a guide for the tests.<\/p>\n Next in line is to ensure that your implementation does conform to the secure OAS file.\u00a0Test not only the \u201chappy path\u201d but all other security related options, for example in the Topcoder case to capture a possible BOLA<\/p>\n Using the 42Crunch Scan tool with the scenario option you can run these test scenarios automatically as part of your build pipeline.<\/p>\n <\/p>\n
\nWithout it I had a great loss, no now<\/em>
\nSecurity, yeah<\/em>
\nAnd I want it at any cost \u2026<\/em>\u201d
\n(Otis Redding, 1964)<\/p>\nIdentify the API Gap<\/strong><\/span><\/h4>\n
Shift-Left with Design Time API Security Testing<\/span><\/h4>\n
\n
\n