We have just updated our API Security platform, and I want to tell you all about it.
100+ New Security Audit Checks
Security Audit checks related to authentication just had a major revamp.
Now instead of generic articles on insecure authentication methods, we provide specific information for each case, including:
- API Key passed as a query parameter
- API Key passed in a header
- API Key in a cookie
- Basic authentication
- Bearer authentication
- Digest authentication
- OAuth1
- Kerberos and NTLM authentication
- IANA registered authentication: HTTP Origin-Bound Authentication (HOBA), Mutual Authentication, Salted Challenge Response (SHA-1, SHA-256), Voluntary Application Server Identification (VAPID) for Web Push
- OAuth2 Implicit Grant
- OAuth2 Resource Owner Password Grant
- OAuth2 Client Credentials Grant
- OAuth2 Authorization Code Grant
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.
All new security checks have been added to our encyclopedia on apisecurity.io.
OAuth Security Best Practices
As mentioned earlier, we are now much smarter about OAuth use in API authentication.
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.
Tweaked Security Issues Impact
Security Audit is now also smarter about how the authentication method is used in the API contract.
If the authentication mechanism is defined (securityDefinitions in OpenAPI 2 and securitySchemes 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.
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.
Enhanced Proxy Handling for On-premises Scan
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.)
You are now able to specify different proxy servers for these two scenarios. You can also do that separately for HTTP and HTTPS traffic.
See Run on-premises scan behind HTTP or HTTPS proxy for details.
Scan Report Improvements
Scan reports now provides information on when the API endpoint was last scanned and also explicitly reports when the “happy path” scenario could not be executed for the particular operation, thus making the fuzzing of that operation impossible:
Other Changes
See our release notes for the list of other changes and firewall compatibility information.
