APIsecurity.io - APISecurity.io Newsletter: Issue 163

This week, AmazicWorld featured a review of why API security strategies are failing to have the desired effect. The author’s view is that whilst developers are well-versed in how to create APIs, security risks that APIs pose are an increasing threat to organizations. These risks are in large part a consequence of rapid API adoption: the sprawl of APIs is widening the threat landscape, and the fact that APIs are well-documented and can be easily reverse-engineered enables attackers to take advantage of them.

The report identified seven top reasons why API security strategies are failing as follows:

• Limited exposure to APIs: Many APIs are developed by teams more familiar with other programming paradigms (such as UI or backend) and who are not familiar with the intricacies of API development, particularly security.
• Lack of visibility: The lack of a comprehensive API inventory is a recurring topic in this newsletter — you can’t secure what you can’t see!
• The growing threat of API attacks: The increasing growth of APIs has led to rapidly expanding attack surface, making defense increasingly challenging.
• Implementation of traditional security practices: Another topic that I, too, keep returning to is the use of legacy security tools, such as WAFs and API gateways, which are simply not capable of providing appropriate API security controls.
• Improper security ownership structure: Some organizations suffer from a lack of ownership and accountability regarding API security.
• Putting the onus of API security on the developer: Developers are increasingly pushed to address API security issues and often do not have adequate time or appropriate tooling for it.
• Rushing to market: Development teams are frequently under pressure to release new features and functionalities, leading to compromises in the security of the related APIs.

There are no easy solutions to many of the topics addressed — the best advice would be to start with gathering a comprehensive API inventory and upskilling the development teams.

Last week saw the annual AWS re:Invent conference, during which the AWS CTO Werner Vogels gave prominent focus to the importance of good API design, as covered by the NewStack. The talk also highlighted a new AWS offering called Cloud Control API, which acts as a unified control for API resources not only on AWS but also from 3rd-party providers.

Of interest to API practitioners are the six best API design practices identified by Vogels:

• APIs are Forever: Beware of phantom APIs, which may still be active but are not assessed for risks or protected.
• Never Break Backward Compatibility: API versioning is key here.
• Work Backwards from Customer Use Cases: Focus on the customer’s needs rather than on what you think makes a useful API.
• Create APIs That are Self Describing and Have a Clear, Specific Purpose: API documentation should be clear and intuitive.
• Create APIs with Explicit and Well-Documented Failure Modes: Ensure users can understand what can go wrong.
• Avoid Leaking Implementation Details at All Costs: Avoid leaking implementation details to minimize coupling to specific technologies and, of course, to avoid security concerns.

Many of these are self-evident to readers of this newsletter, but it’s nonetheless encouraging to see APIs receiving prominence on the big stage.

In our issue 155, we covered the new APIClarity product being developed as a joint collaboration between Cisco, 42Crunch, and API Metrics. This week, Techrepublic featured the views of Cisco’s Vijoy Pandey on the challenges faced by organizations in being able to comprehensively produce an inventory of their API estate. A key takeaway from Pandey is this view on the importance of the OpenAPI Specification (OAS):

“Once you have an OpenAPI spec, you can see what an API is actually transmitting, versus what it was originally intended to do. Say you intended it to pass an integer, but over time people started sending flops. Or you intended two arguments, but over time people started passing three or four, and the API spec hasn’t been updated. These are clear attack vectors,”

From a security perspective, Pandey suggests the following three best practices:

• Leverage the community of security experts in the OWASP organization, such as their excellent OWASP API Security Top 10.
• Focus on the security of your software supply chain using a bill of materials to ensure provenance and governance.
• Consider health indicators of an API — like uptimes or hosting location — when determining if an API is reliable and safe.

As we head toward the end of 2021, it is time to look back over some of the biggest API security attacks of 2021 — this week we feature Security Boulevard’s summary of some of the biggest attacks.

First up is the Parler API hack in January (featured in our issue 116), in which over 60 terabytes of data was leaked affecting 10 million users. Another big one followed in April with the Clubhouse leak (our issue 129), where over 1.3 million records were leaked. In July, the LinkedIn API breach ( issue 140) affected 700 million users and was attributed to inadequate API security practices. Last on Security Boulevard’s list is the NoxPlayer API hack, which we covered in our issue 119.

The key takeaway clearly is that API security is likely to be an ever-increasing concern as API adoption continues to burgeon and attackers focus their efforts on this seemingly vulnerable target.