This week, we have an article from Forbes on why API security is critical in 2023, views from Kin Lane on being pedantic about API contract testing, and a preview of a new tool for API security testing. We also have details of an upcoming webinar on API security within a GitHub environment.
Article: Why API security is critical in 2023
The first article this week comes courtesy of Forbes, which gives a great overview of the state of API security in 2023. The author is of the oft-held view that APIs are the number one attack vector for attackers in 2023, quoting data from Imperva’s “Quantifying the Cost of API Insecurity” (covered here in issue 192), which suggests that the annual API-related cyber loss in the U.S. alone reached between $12 and $23 billion.
The report looks at the various dimensions of API security, from consumer privacy to public safety to intellectual property, and how these have been impacted recently.
Firstly when considering consumer privacy, one needs to look no further than some of the API “mega breaches” I have covered in the last 18 months. Firstly the ongoing Twitter API breach (covered most recently in issue 217) has leaked the personal information of up to 200 million users, according to some estimates. A breach of this scale allows attackers to launch large-scale spear phishing attacks against Twitter users to take over their accounts. Secondly, the Optus breach (covered here in issue 203) led to the disclosure of the PII of up to 2.1 million Australian citizens. To these examples, I would add the T-Mobile API data breach from the beginning of 2023, which leaked over 37 million account holders’ details.
Secondly – and probably even more serious – is the impact on public safety resulting from insecure APIs. The automotive industry springs to mind for a poor record regarding API security, with the most notable example being the research done by Sam Curry into connected vehicles, particularly focusing on their APIs. Early in 2023, Curry’s research revealed flaws in the API of the vehicle management system for Hyundai and Genesis vehicles (covered here in issue 212) which leaked customer confidential information, including vehicle ID numbers (VID). Of more concern was the fact that the researcher could also gain access to the vehicle management system allowing him to control the vehicle’s locks and engine. This is about as serious a scenario as one could get regarding public safety.
Thirdly, the author highlights the significance of API security failings with regard to intellectual property, citing the example of the CircleCI vulnerability, which allowed an attacker to steal or generate new project and personal API tokens. This attack vector could potentially allow an attacker to control the build of any software system using CircleCI and either steal the intellectual property (source code) or subvert the build and release process to inject malware. In this newsletter, we covered similar vulnerabilities affecting the Argo CD platform (in issue 218) and the GoCD CI/CD platform (in issue 159).
I found this to be an excellent article that really highlights the three main API security concerns in 2023: the “mega breach”, personal safety, and intellectual property concerns. As the author concludes, the only way to address this problem is to tackle the root cause by investing in API security.
Article: Getting pedantic about API contract testing
The next article comes courtesy of Kin Lane (@apievangelist), discussing the finer details of API contract testing. This article gives an overview of various API testing strategies based on the Postman API development tool. Lane’s central argument is that many teams feel they are doing API contract testing when in fact, they are only performing basic testing of the API based on the Postman collection (I would be inclined to call this acceptance testing โ it tests that the API behaves in the expected way but nothing beyond this).
To perform genuine contract testing, the first requirement is an OpenAPI definition of your API. In the case of an API design-first strategy, this will already exist as part of the API design process. In the case of a code-first strategy, the team will need to use a proxy or intercept tool to capture the OpenAPI definition from observed network traffic (Postman has this capability natively). Alternatively this OpenAPI definition can be extracted from the API gateway.
Lane advocates a design-first approach where the OpenAPI definition can be used to generate the API collection in Postman from the definition and, in fact, also generate the gateway configuration and policies and the API client and server code from said definition. Finally, by adding various annotations to the OpenAPI definition (particularly on JSON schema), it is possible to fully define the request and response data, including minimum and maximum lengths and other JSON data properties. This is shown diagrammatically below:
As an advocate of a design-first approach, I would always recommend starting with a fully defined API definition (including comprehensive definitions of data structures) and using this to generate all downstream artifacts, including documentation, mocks and stubs, test scripts, and client and server code stubs.
Tools: Fencer automated API security testing tool
Finally, this week, we take a quick look at a new API security testing tool from Josรฉ Haro Peralta (@JoseHaroPeralta) called fencer. The tool is described as an automated API security testing tool, with the goal of seeing how much of the API security testing process can be automated. The project’s initial focus is on the OWASP API Security Top 10 and then to extend beyond this to other common API security vulnerabilities.
The author concedes that the project is in the infancy stage and will require additional work to add a full suite of features. He welcomes contributions or suggestions for features, so any interested readers should get in touch. Certainly, in my experience, there is a dearth of API security-specific testing tools, and any work in this space is valuable. Thanks to Jose for the contribution to the community, and I look forward to updates in the near future.
Webinar: Mastering secure API development with GitHub and 42Crunch
Join Isabelle Mauny (Field CTO) and Colin Domoney (โโChief Technology Evangelist) from 42Crunch next Thursday, July 13 at 9 am PDTย / 5 pm BST as they take a deep dive with live demos into how 42Crunch combines with GitHub to facilitate secure API development:
This practical demo will showcase the following:
- Discover OpenAPI definitions automatically within repositories.
- Audit OpenAPI definitions in GitHub Actions and view results alongside other code scanning tools all in a single view.
- Scan your API for security vulnerabilities directly within GitHub Actions.
- Deploy the 42Crunch API firewall within GitHub Actions.
- Protect your main branch by performing automated testing of APIs directly within the pull request process, allowing informed risk-based decisions for reviewers.
- Using the 42Crunch GitHub application to enrich the pull request annotations further, allowing better decision-making for the reviewer.
- Drive the entire process without ever leaving VS Code!
Learn how to seamlessly integrate 42Crunch within GitHub to prevent vulnerable APIs from ever entering your repository.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
