{"id":10047,"date":"2021-04-16T16:16:12","date_gmt":"2021-04-16T15:16:12","guid":{"rendered":"https:\/\/staging-site.42crunch.com\/?p=10047"},"modified":"2022-09-24T13:12:58","modified_gmt":"2022-09-24T12:12:58","slug":"42crunch-api-security-platform-april-2021-release","status":"publish","type":"post","link":"https:\/\/staging2022.42crunch.com\/42crunch-api-security-platform-april-2021-release\/","title":{"rendered":"42Crunch API Security Platform April 2021 Release"},"content":{"rendered":"
We have just updated our API Security platform, and I want to tell you all about it.<\/p>\n
Security Audit checks related to authentication just had a major revamp.<\/p>\n
Now instead of generic articles on insecure authentication methods, we provide specific information for each case, including:<\/p>\n
All of these get checked for OpenAPI 2.0 and OpenAPI 3.0 standards, and different articles (and severity levels) are used depending on HTTP and HTTPS transport being used.<\/p>\n
All new security checks have been added to our encyclopedia on apisecurity.io<\/a>.<\/p>\n As mentioned earlier, we are now much smarter about OAuth use in API authentication.<\/p>\n 42Crunch Security Audit now checks the grant types used by APIs and warns if these are no longer in line with the OAuth 2.0 Security Best Current Practice from IETF.<\/p>\n Security Audit is now also smarter about how the authentication method is used in the API contract.<\/p>\n If the authentication mechanism is defined ( If we find that the insecure authentication method is, in fact, applied to the API, we will change the score depending on how dangerous the approach is. Insecure authentication applied globally to the whole API will have a higher impact than the one applied to a particular operation.<\/p>\n On-premises Conformance Scan that we introduced in our previous release got its share of enhancements. The agent needs to connect to the API endpoint it is supposed to test and to the 42Crunch platform (to retrieve the configuration and send back the report.)<\/p>\n You are now able to specify different proxy servers for these two scenarios. You can also do that separately for HTTP and HTTPS traffic.<\/p>\n See Run on-premises scan behind HTTP or HTTPS proxy<\/a>\u00a0for details.<\/p>\n Scan reports now provides information on when the API endpoint was last scanned and also explicitly reports when the “happy path<\/a>” scenario could not be executed for the particular operation, thus making the fuzzing of that operation impossible:<\/p>\n <\/p>\nOAuth Security Best Practices<\/h2>\n
Tweaked Security Issues Impact<\/h2>\n
securityDefinitions<\/code> in OpenAPI 2 and
securitySchemes<\/code> in OpenAPI 3) but not actually applied, this is a lurking danger (that someone accidentally starts using it in the future) and not an immediate vulnerability. Thus, we will warn if we see such a definition but will not lower the score because the authentication method is not used.<\/p>\n
Enhanced Proxy Handling for On-premises Scan<\/h2>\n
Scan Report Improvements<\/h2>\n
Other Changes<\/h2>\n