With the shift to REST APIs, the risks involved in DevOps culture is increasing because of new attack vectors. What can be done to counteract this? To find out I asked an expert to share his thoughts with us on this subject. Dmitry Sotnikov is an 11-time recipient of the Microsoft MVP (Most Valuable Professional) award who curates APIsecurity.io, a community website for all things related to API security. For those of us who are security-minded (and who isn’t nowadays?) let’s pay close attention as Dmitry walks us through the risks and challenges of API security and how this relates to the DevOps culture.
API security is becoming a big deal and the industry is reacting
The proliferation of web APIs has dramatically increased the attack surface, and API attacks are on a steep rise. In fact, Gartner predicts that APIs will become the No. 1 attack vector by 2022. Traditional web application security is not able to help due to the change in technology and architecture. The industry is reacting with new API security guidance like OWASP API Security Top 10, and DevSecOps solutions for API Security.
APIs are everywhere and attackers are noticing
Companies used to have a relatively small number of APIs, mostly to connect to a limited number of internal or partner systems. Not anymore:
- Mobile applications, rich web applications (single page applications), IoT devices, cloud-based applications — all rely on APIs to power them.
- Lots of functionalites such as communications, billing, analytics, and so on are getting outsourced to third-party online services and invoked via APIs.
- Transition to microservices architecture is leading to massive application decomposition in which internal components are becoming independent services exposing and consuming APIs and all communications happen over the network.
As a result, according to Akamai, 83 percent of all web traffic is now API traffic. This growth of APIs is resulting in the corresponding change in the attack surface and threat model. Gartner estimates that by 2021, exposed APIs will form a larger attack surface than UIs for 90 percent of web-enabled applications.
And this is happening already. Just in 2019 alone, we observed a lot of high-profile API breaches and vulnerabilities including the ones at Facebook, Amazon Ring, GitHub, Cisco, Kubernetes, Uber, Verizon, MuleSoft, Tinder, First American, Fortnite, and even the Vatican, to name a few.
API security is a challenge
This sudden change has caught the industry by surprise. REST APIs were designed to be very similar to regular web application calls. They have inherited the same approach of invoking GET, POST, and other operations over HTTP (or HTTPS) transport. Thus, there has been an implicit assumption that traditional web app security tools (such as web application firewalls and web server scanners) would cover API security as well.
But API-based architectures are very different:
- A lot of logic is at the client or API consumer side and APIs are returning or consuming (as opposed to clients just rendering HTML coming from the app server in the old days).
- API clients maintaining their state and passing it as parameters in API calls.
- APIs are structured and can often be explored or guessed.
- APIs are exposing internal, intercomponent logic and not just end-user interface thus enabling attacks on the very logic of the application implementation.
As a result, 86 percent of WAF users are now reporting their WAF missing attacks.
To make things worse, each of these APIs or microservices behind them has a team that is doing their best to stay agile. With weekly, if not daily, updates from dozens (or hundreds or thousands) of microservices teams inside the company, security teams simply do not have bandwidth for any manual security reviews.
OWASP API Security Top 10
OWASP is a nonprofit organization devoted to popularizing cybersecurity. Since 2003, they have been issuing and updating their famous OWASP Top 10 for web applications. In these documents, API security has only been tangentially mentioned. However, the new security risks unique to APIs have become a driving force behind a new top 10 list specific to API security itself:
- API1: Broken object-level authorization
- API2: Broken authentication
- API3: Excessive data exposure
- API4: Lack of resources & rate limiting
- API5: Missing function level authorization
- API6: Mass assignment
- API7: Security misconfiguration
- API8: Injection
- API9: Improper assets management
- API10: Insufficient logging & monitoring
Last year, OWASP API Security Top 10 was launched as a separate project.
For a deeper dive into the OWASP API Security Top 10, you can watch this webinar. And download 42Crunch’s cheat sheet for summaries and remediation guidance.
DevSecOps and API security
Let’s face it: Developers are already busy. They are told to stay agile, innovate quickly, and enable their businesses to stay ahead of the competition. DevOps processes, CI/CD, cloud, and microservice technologies (such as Docker and Kubernetes) gave them the power to make incremental changes and push them out faster. However, these same technologies made the systems more complex and vastly expanded the attack surface. Handling security as a separate specialized task to be done after the product release from development has proven ineffective and inefficient. Security teams miss multiple gaps and slow down the innovation process in the company.
The only real way to handle the complexity and the agility of API security is to shift API security left and automate it. “Shift-left” means that API security is no longer just a runtime security issue but also something that developers embed in their API design and testing. Shift-left and DevSecOps are trying to solve the problem by embedding security design and testing into the development process and CI/CD pipeline. These efforts will succeed or fail depending on how they are implemented:
- Embed security into existing pipeline and developer tools to minimize the learning curve and overhead and simplify adoption.
- Establish common security standards, policies, and metrics across security, developers, quality control, operations — everyone needs to speak the same language.
- Use security tools that provide prescriptive guidance so developers know what they need to fix and why. For example, which third-party libraries need to be updated and to which versions, which base Docker images need to be fixed and how, and which APIs have flaws in their design and implementation and how to remediate them.
- Make sure that the tools give output that you can use to proceed with the DevSecOps pipeline or to block the developer change: a grade that you can use to make the decision (above or below threshold), presence of critical flaws, and so on. There needs to be a clear way to make automated decisions.
- Cover each phase of the system’s lifecycle: static (code and design), dynamic (behavior tests), and runtime (protection).
Companies like 42Crunch (disclosure: the author of this article works there) offer commercial API security tooling that can be embedded in your pipeline.
Free API security tools
There are also a couple of free security tools available to API developers. Developer tools such as Microsoft Visual Studio Code now have API development extensions that include Security Audit. (Click here for more information.) If you do not want to install any tools locally, there is also an online API security audit tool available here.
Meeting the threat
API security is rapidly becoming one of the biggest challenges in IT. Luckily, industry guidance and community and commercial tooling are emerging to help you design and maintain your API security.
Featured image: Shutterstock
