This week, we have an article on the rise in API breaches as a result of credential leakage and how this can be addressed by using “MFA for APIs”. We also have a thought-provoking read on how to select an API gateway based on its security characteristics and a brief review of PCI DSS 4.0’s impact on secure API development methodology. Finally, we have news of the recently released “Black Hat GraphQL: Attacking Next Generation APIs” book.
Article: Credential leakage fueling the rise in API breaches
First up this week, we have a timely article from Security Week on the rise of API breaches arising as a result of credential leakage. The article is based on recent research by Corsha (an IDAM provider focusing on APIs) who surveyed over 400 US-based professionals on their API security posture. Of these, 53% had suffered an API breach, while 77% felt that their organization effectively managed their API tokens. This leads to a somewhat paradoxical conclusion that whilst many professionals are confident in their credential management, they suffer credential-related breaches regardless.
The report concludes that there are three fundamental causes behind this apparent contradiction, namely:
- A lack of visibility into their portfolio of existing APIs.
- The sheer volume of APIs that are in use makes them hard to track.
- Underestimating the time and effort invested in managing those API credentials.
The survey measures the effort (and hence cost) associated with credential management and claims that most respondents spend more than 15 hours per week managing credentials. Although this is probably a very rough estimate, it indicates how costly credential management is becoming. As they note, this problem will only worsen as API sprawl continues unabated and build environments become more distributed, requiring more credential distribution and management. As the scale of the challenge grows, organizations will be left with a Hobson’s choice of either ignoring the problem or spending more money on an activity that is not revenue-generating.
Corsha’s solution to the problem is interesting and can be loosely described as “MFA for APIs.” The solution offers three advantages:
- MFA from machine to machine allows micro-segmentation, which prevents lateral movement in networks.
- One-time MFA between machines reduces the risk of “MFA fatigue, ” a common attack vector used against humans.
- The problem of credential rotation is largely removed since stolen or leaked credentials cannot be used without satisfying the MFA requirements.
It will be interesting to see how Corsha progresses with its product โ certainly, credential leakage is a very real problem for APIs.
Article: How secure is your API gateway?
The next article is a really interesting read from The New Stack on the importance of the security of your API gateway. The author believes that because the API gateway is such a critical piece of infrastructure, it is important that those responsible for deploying gateways fully consider the security of the gateway itself. Due to their tight coupling into an organization’s infrastructure, API gateways are infrequently changed, making it much more important that security is a top consideration when choosing the gateway. The author considers four factors contributing to an API gateway’s overall security posture; let us look at each of the four in turn.
Firstly, API gateways are often built on top of an open-source implementation with a bespoke closed-source layer. This makes it important that vulnerabilities within the entire software stack are tracked and managed using modern Software Bill of Materials (SBOM) techniques. This gives the buyer an informed view of the risk inherent in the gateway implementation. Similarly, the buyer should consider other factors, such as the SLA for remediating zero days vulnerabilities.
Secondly, the buyer should consider how well the gateway integrates with other security elements such as web application firewalls (WAFs), global firewalls and load balancers, and monitoring platforms (SIEMs/SOCs). Tight integration is important to ensure adequate application performance and also, importantly, to minimize the impact on operational teams when deploying new versions in complex hybrid multi-cloud environments.
Thirdly, a buyer in a large organization should consider how well the same policy can be enforced across the entire organization, which may be built on top of a very heterogeneous technology stack. The author cites the example of different underlying reverse proxies, which may implement the same policy in a different manner. These subtle differences may only become apparent with very fine-grained policies, which may often result in a compromise where the operators are forced to fall back to more basic policies leaving gaps in protection. The only way around this is to ensure that the buying organization conducts a thorough proof-of-concept (PoC) before purchasing.
Finally, the speed (latency) of the gateway is critical for its adoption and long-term success. If a chosen gateway is shown to be poorly performant, then unfortunately, API teams will seek to detune policies or, in the extreme, to bypass the gateway entirely. The performance of an API is often a critical factor in its success, and if a gateway impacts the performance, teams may resort to shadow IT practices to deploy their APIs.
This is a really interesting take on a well-trodden topic and worth considering if you are evaluating API gateways.
Article: The impact of PCI DSS 4.0 on API security
The PCI DSS standard is among the most widely applicable standards for software providers affecting anyone who processes payments by card. The most recent version 4.0 makes specific provisions for the secure development and deployment of software; our next article looks at how the standard’s provisions will likely impact API developers.
There are several key clauses specific to the development and deployment of software; for each of these, the author reviews best practices for API development to ensure adherence to the standard.
6.2 โ Bespoke and custom software are developed securely.
This is guidance to adopt a secure SDLC or to embrace “shift-left” development. For API development, developers must be aware of security requirements as early as possible and utilize secure development methodologies throughout the lifecycle.
6.2.3 โ Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities.
This clause guides developers to use code reviews – of both OAS definitions and API code – to ensure that the implementation is free from coding vulnerabilities as far as possible. These reviews can also be automated at various stages through the development lifecycle to ensure vulnerabilities are removed at every opportunity.
6.2.4 โ Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software.
In an API context, this control dictates the use of advanced testing methods to identify various software attacks on APIs. The recommended best practice is to use specific API testing to detect well-known vulnerability types (such as broken object-level authorization and broken authentication) using automated testing (dedicated API security scanning tools) or via bespoke penetration tests.
6.4 Public-facing web applications are protected against attacks.
Finally, the standard specifies that public-facing APIs should be protected against attacks, typically via API gateways or dedicated API firewalls.
There are probably no great surprises here for our readers, but it is a timely reminder that these controls are actually mandated by PCI DSS 4.0.
Book: “Black Hat GraphQL”
We seldom feature book reviews in this newsletter, and I was reminded of a top book recommendation seeing a Tweet from @hAPI_hacker recently. Recently Nick Aleks (@Nick_Aleks) and Dolev Farhi (@dolevfarhi) released their joint collaboration “Black Hat GraphQL: Attacking Next Generation APIs” on No Starch Press, and it is receiving favorable reviews from many quarters. There really is a scarcity of top-notch security resources on GraphQL, and this book is a must for both attackers and defenders alike.
Thanks for the contribution to the community, Nick And Dolev!
Event: Gartner Security & Risk Management Summit
The annual Gartner Security & Risk Management Summit takes place next week in National Harbor, Maryland.
If you’re attending, be sure to visit the 42Crunch Booth #254 to learn all about our
latest features and innovations to help improve your API Security Testing and API Threat Protection.
You can also book a meeting with any of the 42Crunch onsite experts to discuss your API security challenges and strategy.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
