Building API Context with a New Tech Talk Video Series

Comparing traditional web apps and API-based apps

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.‍

APIs have been around forever — didn’t we take care of security long ago?‍

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.‍

APIs expose critical infrastructure‍

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.‍

Next up

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.

Want to learn how Salt can help you secure your APIs? Request a personalized demo to see how Salt helps you discover all your APIs, prevent attacks, and improve your API security posture.