Today we’re kicking off a new tech talk video series called Building Context, where we’ll be covering a range of topics around APIs and API security.
In this first episode, Michael Isbitski, Salt Security Technical Evangelist, joins and brings a wealth of knowledge from his five years on the Gartner for Technical Professionals (GTP) team, where he advised hundreds of customers about API security. Before Gartner, Michael spent over 15 years at Verizon focused on API and application security, so it’s safe to say he’s seen it all, or close to it, and brings some great perspective to the conversation.
In APIs Have Broken Your Security, Michael and I discuss how APIs have made traditional application security tools and approaches less relevant. While some of these methods still play an essential part in security, they don’t go far enough to protect most applications today that are powered by APIs.
Here are some highlights from the discussion:
Starting off the conversation, we frame the problem with the reality that the majority of applications today are API-based. If you have any doubt that APIs are everywhere around us and usage is increasing, here are a few data points to consider:
Next up, we talk about the difference between traditional web applications and API-based applications. This comparison is an essential frame for the rest of this conversation and future episodes of this series. I shared details about this in the previous blog post, Securing APIs – It’s Different Than Securing Apps, and it boils down to where the processing takes place and where the logic is exposed.
With traditional applications, the majority of the processing and application logic resides in the data center powered by three-tiered infrastructure that includes a presentation tier, processing tier, and data tier. With this architecture, a traditional application receives a request from a client triggering a query of data from a database. A web server renders the page using the data and sends the rendered page back to the client.
The majority of traditional web application attacks target components of that three-tiered infrastructure. Organizations frequently relied on authentication, authorization, and encryption as well as firewalls and Web Application Firewalls (WAFs) to protect these apps.
API-based applications expose much more of the application logic and data outside of the data center. As an example, a client will make a request over an API, the application will respond with raw data (often more than is needed), and the client is left to render the view. Attacks targeting API-based apps target the API logic, and attackers look for ways to manipulate that logic to gain unauthorized access to data. More on this below.
Most protections used for traditional web apps still have their place with API-based applications, but they are far from enough since most of the attack surface for API-based apps is exposed externally and different API consumption patterns make them less suitable.
As we discuss further, it’s true, APIs have been around for the better part of 20 years, so it’s common to think that we’ve taken care of security. To some extent, that assumption is correct. APIs have not existed all this time without having some level of security. Authentication, authorization, encryption, and rate-limiting have been used for years to protect applications, and they still have a place in securing API-based applications. Even security functions of development tooling and traditional controls like WAFs attempt to extend to APIs, but none of this goes far enough.
Public-facing applications mean authentication can be a low bar for an attacker to step over. Within a matter of minutes, an attacker can sign up for an account and gain access to the API. Even more restricted applications are not immune from a determined attacker who will either try to brute force authentication, phish credentials, or purchase a list of usernames and passwords.
The widespread use of APIs and constant change make authorization challenging to define and impossible to maintain. API-based applications create a complex web of logic and data pathways. Proper configuration of authorization and permission sets require deep knowledge of that logic. Adding 3rd party APIs and rapid development makes defining and maintaining authorization an even more significant challenge.
APIs today are a lot more exposed than they were in the past. It’s easy enough for an attacker to proxy an API connection on their own endpoint to see raw data and API details, so encryption provides only partial protection for data in transit.
With the combination of the wide use of APIs, constant change, and increased exposure, some vulnerabilities are found only at runtime. While development-time security is important with secure coding best practices and code scanning, vulnerabilities will inevitably make their way to runtime.
Some organizations employ web application firewalls (WAFs) to protect applications at runtime and have extended them to try to protect API-based applications. But as I outlined in my post Stopping API Attacks: Columbo, Correlation, and Context, these tools are limited by architecture and do not have the context needed to identify and stop API attacks.
We wrap up the discussion by talking about how APIs have changed the attack surface and increased exposure . APIs used to be primarily internal components with limited to no exposure externally. That’s no longer the case with APIs that power customer and partner-facing applications.
These externally exposed APIs are an essential part of digital transformation and critical components of services that generate revenue. They’re exposed by design, driven by business need, and it’s not practical to think that you can simply lock them down to protect them.
Because APIs are critical components of revenue-generating applications and expose critical data, attackers have taken note and have made APIs a top target. We saw proof of this in the Salt Security 2021 State of API Security report, where 91% of respondents experienced an API security incident
last year. External exposure means that it’s easier than ever for an attacker to map your API, understand the logic, look for vulnerabilities to exploit, and extract data.
We hope you enjoyed the conversation as much as we did and learned something along the way. We already have a few other videos planned for release, so stay tuned for more. In the meantime, we’d love to hear your thoughts and comments about this topic as well as ideas for future conversations in the series.
It’s extremely important to make sure your OAuth implementation is secure. The fix is just one line of code away. We sincerely hope the information shared in our blog post series will help prevent major online breaches and help web service owners better protect their customers and users.
We want to thank our customers, partners and friends for the calls and messages to our team showing your concern and support.