Subscribe to the Salt blog to learn about the latest developments in API Security

Blog Post

MythBusters API Edition: Zero Trust and its limitations for API Security

Michael Isbitski
Apr 20, 2021

Defining “zero trust”

Before we dive into why “zero trust” has become a myth in API security, let’s establish what we mean by the term since it is often overloaded in the security industry. Traditional security thinking asserted that if we can build trusted environments (commonly network zones) to host applications, systems, and data and operate with least privilege access, then any resources within those trusted environments can be considered reasonably protected. This line of thinking shaped organizations’  perimeter thinking for decades, particularly when it came to building out on-premises data center environments.

The erosion of trust in modern computing

Threats regularly erode the concept of trust – especially trust in a perimeter – in modern computing. This erosion comes from external attackers abusing APIs, compromised supply chains, malicious insiders, and a large array of other real-world threats. The problem is exacerbated with modern architecture, where systems are moved out of a controlled data center environment and increasingly connected (usually with APIs) to facilitate business, enable employees, and serve customers. Ultimately, no resources can be deemed safe or secure. Security practitioners must consider a resource to be untrustworthy, enforce least privilege access, and validate continuously whether permissions are appropriate for users, machines, and data.

New ideas spawned from the zero trust movement

A number of concepts and technologies emerged from zero trust principles. Software defined perimeters and microsegmentation are frequently mentioned. Two items in particular often arise in API security conversations:

  • Zero trust architecture (ZTA) - promotes the idea of network perimeters, though they may be referred to as microperimeters. ZTA also still promotes the idea of segmentation and microsegmentation, though enforcement of access control can also now exist closer to workloads. It can result in technology mashup of Kubernetes ingresses, service mesh ingresses, microgateways, sidecar proxies, container runtimes, virtual machine hypervisors in addition to routers, gateways, network load balancers (NLB), and application delivery controllers (ADC). Definitions of workloads, gathered workload telemetry, and behavior analysis of the collected data can be used to make dynamic network access decisions. ZTA aims to reduce the attack surface and limit blast radius in the event of infrastructure or workload compromise.
  • Zero trust network access (ZTNA) - focuses on protecting employees as they connect to environments or cloud-delivered (i.e., SaaS) services and read or modify data. ZTNA has emerged as a replacement for traditional remote access mechanisms like VPN. Traditional VPN approaches often did not cut it for organizations, offering poor user experience, low throughput, minimal security benefit, or all of the above. Once a user is in a “trusted channel,” additional security capabilities can be enabled such as conditional access control, DLP, behavior analysis, and anti-malware. Some of these security capabilities are filled by cloud access security brokers (CASB) today. Secure access service edge (SASE) is also emerging, which combines respective security capabilities of CASB and ZTNA.

Why “zero trust” is not API security

To put it bluntly, the reason ZTA and ZTNA don’t help dramatically in an API security strategy can be distilled down to one key point:

The goal of zero trust is to restrict access, but access is critical in order for APIs to function.

Gone are the days where APIs might exist purely as middleware, sit within inner architecture, and be exposed to only a subset of partners or suppliers, where IP address allowlists or VPN might be suitable controls. Access control methods break down in API security for a number of reasons, including:

  • APIs may be designed as public APIs or open APIs – APIs may be designed to be consumed by the broader internet and a large customer base. Public or open APIs are common in retail, eCommerce, FinServ and FinTech industries. This makes the IP address space of API consumers a relative unknown since users and traffic may originate from anywhere. It also becomes difficult to rely on traditional controls like rate limiting since there may be periodic traffic spikes that are perfectly normal. Typically, an organization would start to lean more towards IAM measures to provide some element of protection and sideline the traffic management controls.
  • APIs may be public and anonymous – taking the exposed API concerns a step further, an API may be designed to be public and anonymous. Some well-known examples include citizen services or map and navigation services. These types of scenarios make network access control and IAM ineffective.
  • API attacks occur in trusted network channels – attackers man-in-the-middle TLS connections through protocol attacks, compromising client-side code, compromising endpoint devices, or compromising network elements.
  • API attacks occur in authenticated sessions – attackers piggyback or hijack authenticated sessions by stealing active session cookies, authentication tokens, 2FA challenges, API keys and other authentication material. These are readily extracted from application traffic, client-side storage, or client-side code.
  • API attacks occur in authenticated sessions within trusted network channels – the security industry as a whole has long advised that apps and APIs are deemed protected if they use encrypted transport such as TLS as well as authenticate and authorize users. This approach still fails to address the application layer and is only one piece of the API security puzzle. Network, identity and session attacks still work much to the delight of attackers, as evidenced by the many API incidents and breaches where the service provider used HTTPS with TLS and enforced proper authentication.
  • APIs are often consumed by machine identities – when you are dealing with pure machine communication and data flows, prompting is a nonstarter. ZTNA solutions and some elements of ZTA like enforcing 2FA simply can’t be used in machine to machine or direct API communication. There is no user to respond to a challenge, and you wouldn’t want administrators to be approving machine communications as they occur. Challenging or necessitating manual intervention creates massive inhibitors in cloud-native design and DevOps initiatives.
  • Metadata to inform access controls is often lacking - Metadata about a machine identity to inform access controls may be lacking if appropriate tagging and labeling isn’t performed by owning teams or version control practices are immature in the organization. Compute may also be highly ephemeral such as what often happens with containers and serverless.  

Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.

(Machine) identity is at the heart of security

Identity forms the foundation for network security in the zero trust world, and the realization soon emerges that authenticating and authorizing machine identities (i.e., services or service communications) is incredibly complex in practice. It must be done seamlessly with an eye towards automation. You can’t challenge a machine identity for authentication material like you can with a user in an interactive session. Secrets management, certificate-based authentication, microsegmenting based on workload labeling and tagging, Kubernetes namespace isolation, Kubernetes network policy, open policy agent (OPA), and service meshes are some tools of the trade depending how far you’ve advanced into the world of cloud-native. Some technology is still emerging, best practices can be at a premium, and engineers often find they are early in the learning curve. Regardless, these approaches still only address access control and do not cover application layer security.

The lifeblood of APIs...connectivity

The APIs you build and integrate need to be able to communicate to many different types of user and machine identities across many different environments. Communication paths are difficult for engineers to quickly grok and relax or restrict accordingly. Opening rules in firewalls along with the associated paper trail and change management still common in most organizations will never scale. This shortcoming holds true even if routing rules and configuration are machine assisted, since many organizations still require formal change management as mandated by compliance or regulation.

Context is king

Technologies designed with zero trust in mind might tout that they parse “application context,” but it warrants further review. They may parse service communications, but they don’t aim to understand application layer or API context. They are about as application-savvy as firewalls of old, understanding ports and protocols used by workloads and little else. My colleague Chris expanded further on the importance of API context in the post Stopping API Attacks: Columbo, Correlation, and Context. Just like real-world security checkpoints on bridges that inhibit vehicle traffic flow, expect access control methods like zero trust to impact API performance and availability. HTTP/S and ports 80/443 inevitably must be open for API communications, particularly for internet-facing, public APIs. The range of identity types you are dealing with may also be immense. As a result, traditional access control approaches, even ZTA and ZTNA, are a nonstarter for many organizations.

Traffic management dressed as API security

I’ll dig in deeper on IAM, API gateways, API management and WAFs in a future blog, but proxy-based mechanisms often claim they provide API security features. If you peel away a few layers of the onion, you’ll find many of these features are essentially network security by another name, possibly labeled as traffic management or threat protection. Some vendors may even claim they are useful for enabling zero trust. The common features that you can often find in any network component along with the associated attacker bypasses include:

  • IP address allow and deny lists: attackers distribute their attacks, spoof originating IP addresses, employ zombie hosts/botnets, or leverage gray market device farms to evade such controls.
  • Rate limiting: attackers will throttle their own requests when performing reconnaissance or attacking (aka low & slow) or distribute attacks across IP address spaces to evade rate limits. Static rate limiting almost always falls over for organizations. Dynamic rate limiting, if offered, doesn’t provide adequate API context to be effective.
  • Access control based on HTTP patterns: attackers regularly modify HTTP header values and message bodies such user agent strings, cookies, authentication headers, and JSON payloads. For many application scenarios, especially with some type of front-end functionality like a web application, mobile application, or connected device, such data is controllable by the user and easily manipulated.


Zero trust principles and the technologies that have emerged inevitably promote dynamic access control that is informed by application context, identity, and behaviors. Identities may be users or machines, depending on the scenario. Access control has moved on from basic access control lists, firewalls, and point in-time access decisions at well-defined perimeters to something more distributed and continuous. The intersection of network access control and identity and access management results in identity as the new perimeter. At the end of the day, these approaches and technologies are still about restricting access or connectivity to enforce least privilege in untrusted computing environments.

One of the principle tenants of zero trust is continuous monitoring and behavior analysis to inform access control decisions. This is certainly one component of an API security strategy, since an organization will likely want to terminate access real-time for abusive API calls or sensitive data exposures. Unfortunately, the technology offerings born out of zero trust do not adequately parse application and API-layer behaviors. Organizations focusing on zero trust security principles need to ensure they are also looking at newer breeds of tooling that can augment their zero trust technology investments and provide the context that is necessary to protect APIs and the applications powered by them.

I’d encourage you to take a look at the API Protection Platform offering from Salt Security to fill this gap in zero trust. You’ll find ample resources on our site, but please also reach out for personalized demonstrations or additional technical questions.


Salt Security Blog

Sign up for the Salt Newsletter for the latest resources and blog posts.

June 18, 2024

Salt Labs
Research Team

Salt Labs

Increasing API Traffic, Proliferating Attack Activity and Lack of Maturity: Key Findings from Salt Security’s 2024 State of API Security Report

The latest Salt Security State of API Security Report is out now, and we’re thrilled to give a little sneak peek of its contents.

Read more

June 12, 2024

Elad Hoffer
Head of Product R/T Protection


Salt Security Leading the Way in AI-Driven API Security for Next-Generation Threat Protection and Attacker Insights

Learn how the recent introduction of advanced LLM-driven attacker insights further solidifies Salt's position as a leader in API security solutions.

Read more

June 7, 2024

Eric Schwake
Head of Product Marketing

A Salt Security Perspective on the 2024 Gartner® Market Guide for API Protection

Salt Security's API Protection Platform is AI-infused and designed to address the challenges outlined in the Gartner report.

Read more

Download this guide for advice on evaluating key capabilities in API Security

Learn everything you need to know to keep your APIs secure

Get the guide