Protecting Web APIs: The Forgotten Realms

“A near miss today could be an accident tomorrow.” Earlier this year we got a glimpse of how true this saying is, this time around with regards to a global retailer's customer records.

A “trivial” path traversal attack on one of the company's APIs led to a potential leak of nearly 100 million customer records. Fortunately, the vulnerability was discovered as part of a bug bounty program and was responsibly disclosed and patched.  

This latest potential breach dealing with protecting web APIs is one of many we have witnessed in recent years, leading to a highly negative impact on the privacy of millions and the public trust for highly reputable large firms.

Other incidents since 2018 include a developer's API breach that exposed accounts of 50 million social media users; a broken API for a shipping website that exposed data for 60 million user accounts; abuse of API services that exposed up to 309 million social media users' IDs and phone numbers; and an API breach for a financial services app that allowed mass scraping of 200 million transactions. 

When evaluating your web application’s security posture, you must keep in mind what might be the weakest link in the chain of protection. Instead of dealing head-on with security measures of the “main gate,” attackers seek potential unattended cracks through which they may get through. APIs are the perfect candidates from an attacker’s perspective. 

Why Target APIs?

If you’ve been following the evolution of web application architecture in recent years, the trend is quite obvious. Web applications are moving away from monolithic designs, shifting to microservices based architecture, most commonly implemented using cloud native technologies due to their inherent advantages – CI/CD independent pipeline, auto scaling and high portability. 

APIs, short for Application Programming Interfaces, are the “glue” of such microservices, enabling communication between different backend and frontend services for the application. So why do attackers favor them so much?

Classic application security measures seem to struggle with securing APIs. Consider the following:

Rate

By nature, APIs are intended for machine-to-machine communication. Thus, applying client-based rate limits might be challenging or oftentimes inapplicable.

Human/Bot Challenges

Challenges meant to detect and block automation tools are nearly impossible to implement when protecting an API endpoint due to the response content-type (usually JSON or XML), which does not allow for injection and rendering of javascript challenges or CAPTCHA injection. In other cases, APIs are used for programmatic access by design, so there’s no point in deploying bot detection measures.

Security Awareness

Since microservices are loosely-coupled, it is often the case that multiple teams develop them independently, each applying different secure coding standards. The end result for medium-to-large organizations is hundreds of exposed APIs internally and on the perimeter, with the security team struggling to identify them, track changes to them or apply proper protections. 

Hybrid Deployment

Not all microservices are deployed in the same environment. Some are deployed on-premises, some in public clouds, some in private clouds hosted by third parties. And throughout their lifecycle they are moved between different environments, some internal and some externally facing (e.g. test, QA, lab, corp, production etc.). This poses a problem for security measures deployed on the perimeter since there is no visibility to internal environments or communication among services within the perimeter (i.e. “east-west” traffic).

In practice, all of the above-mentioned considerations make APIs a convenient target for all sorts of popular attacks such as credential abuse, web scraping, command injections, SSRF (Server-side Request Forgery), local file inclusions and more. 

As a matter of fact, protecting web APIs has become such a need in the world of application security that in 2019, the OWASP foundation initiated a separate project tracking Top-10 API Security Risks, saying:

“By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this, have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.”

API Security Done Right

Hopefully by now you are convinced that API security requires attention and relevant protection measures. Here are some key considerations when choosing an API protection solution:

Support for Positive Security

OpenAPI specification (formally known as Swagger) allows for standard definitions of API capabilities. A solution for protecting web APIs should be able to enforce communication to APIs based on such specification files, taking into account allowed methods for each endpoint, input parameters and value format. All of these can be explicitly defined using the specifications and should be easily imported to your firewall as definitions with a single click.

Near-Application Deployment

Focusing all protection efforts on the perimeter would only provide for a partial solution. Protections should be deployed as close to the application as possible. Your security solution should provide visibility into inbound conversations (north-south traffic) as well as internal communications from other microservices (east-west traffic).

Runtime Protection

Having a top-notch application firewall inspecting incoming traffic to the application is not enough. Any firewall, as good as it may be, is prone to false negatives either by a sophisticated evasion technique or a nasty zero-day vulnerability. To mitigate such risks, a holistic solution should also monitor the behavior of the web application during runtime as an additional layer of protection. Such a solution should learn the normal application behavior and alert on any unexpected outbound traffic from the application (to the Internet or to other servers within the perimeter), unexpected processes spawned, increased CPU usage or any other suspicious activity.

Scalability

As incoming traffic to the protected endpoint scales, so should your solution scale to avoid service outage or unwanted bottlenecks. Ideally your solution of choice should be able to auto-scale, thus avoiding the risks of long-term capacity planning and the unnecessary cost of purchasing over-capacity to allow for future growth.

Unprotected API Detection

You cannot protect assets that you are unaware of. Your solution of choice should have the ability to continuously scan your deployments and alert for unprotected web applications.

Implementing API Security

As the world of web application development shifts toward the use of APIs as part of cloud native microservices architecture, security solutions should evolve respectively.

Most of today’s microservices run as orchestrated containerized applications deployed in a hybrid manner – some on-premise and some hosted in public clouds.

To rise up to the challenge, we at Palo Alto Networks have been working hard in the past several months on our Web Application and API Security (WAAS) module making sure we come up with a holistic solution for protecting web applications.

We are excited to share some highlights:

Close Protection Everywhere

WAAS runs in proximity to your web applications as part of your deployment, whether that's in the form of orechastated containers, hosts, serverless functions, on-premise or cloud hosted. Being deployed so close to the application, WAAS is able to inspect both inbound traffic from outside the perimeter as well as east-west traffic from other entities within the perimeter.

Broad Protection Coverage 

WAAS provides protection against all OWASP Top-10 attacks, with specific measures to help nearly eliminate false positives. APIs are easily defined by importing OpenAPI/Swagger files, WAAS will enforce incoming traffic based on the API specification provided.

Auto-Scaling

As part of its inherent cloud native capabilities, WAAS is easily scaled up or down to fit your deployment needs and avoid unnecessary costs.

Runtime Protection

As part of Prisma Cloud, WAAS can leverage runtime protection capabilities in addition to traffic inspection. Runtime protection learns the behavior of your web application over time and alerts for any unexpected anomalies.

Unprotected Endpoint Detection 

WAAS continuously scans your deployment for new web applications, and will flag any unprotected applications in the Radar view.

Begin Protecting Web APIs

The capabilities highlighted above are automatically available to Prisma Cloud users who deploy the Prisma Cloud Defender to protect host or container runtimes. 

Learn more on our dedicated WAAS webpage.