The old mentality of building a moat around important assets and trusting anyone or anything that is already inside the castle perimeter has failed us. Attackers have developed many techniques to jump the moat and scale the castle walls to get at what they want. Thus, the new rallying cry is to implement Zero Trust–the notion that no entity – human or machine, inside or outside the perimeter – should be trusted unconditionally until authenticated, authorized, and continuously monitored for threats. 

The global pandemic has really driven the need for Zero Trust as organizations turn to remote-first work strategies and total distributed teams. Workers (and their devices) are routinely located outside any remaining vestiges of a network perimeter and should be fully qualified before given access.

Looking beyond people, there’s another critical area that we must consider for a Zero Trust security model: APIs. A Zero Trust approach is relevant for both clients and servers.

API security is an essential part of any cybersecurity program inside any organization. It can be split into three main parts: 

1. Authentication
2. Authorization
3. Threat prevention

Zero Trust ideology should be applied to them separately. It means, in particular, that you should use threat prevention mechanisms even for authenticated and authorized API connections. 

In other words, application security teams should enable threat prevention equally for authenticated clients, authorized API endpoints, and unauthenticated and unauthorized entities. 

Let’s now look at API security from endpoints’ and clients’ origins point of view to check how the Zero Trust plays there.

To understand how to apply Zero Trust to API security, we have to split all the clients of protected APIs by the categories: 

1. Internal APIs, microservices, and sidecars. This is all about east-west communications and service mesh.
2. External APIs. These are all the 3rd party APIs from the outside of the company’s physical and virtual infrastructure.
3. API direct customers. These usually are partners or B2B partners’ services. This is specifically relevant for SaaS B2B products that sell API calls.
4. API web clients. These are Single-page Applications, a.k.a. SPA, that use REST or GraphQL APIs as data sources and render their data to the beautiful UI in the browser. The most popular frameworks here are ReactJS and Angular.
5. API mobile app clients. Mobile applications use REST or gRPC API backends and data sources to render UI on our mobile phones and tablets.

Now we can build the following matrix to help DevSecOps and application security teams understand Zero Trust for API security in a simplified form:

In the table above, we put an average case related to the typical SOC2-compliant B2B company with API-based products.

As you can see, there are a lot of gaps in threat prevention for internal and external APIs. The main reason is the complexity of parsing API data protocols. 

Here are critical considerations for imposing Zero Trust on your APIs.

1. API Protocol support
   Your API security solution should support all the relevant API protocols, including REST, SOAP, graphQL, gRPC, and websockets. You might have some legacy stuff as well as projects with a cutting-edge stack. Make sure your API security really supports those protocols, has all the relevant parsers, doesn’t introduce latency into the traffic processing flow, and provides protection against relevant threats from well-known OWASP Top 10 attacks to sophisticated threats and 0-days.
   
2. API Deep Request inspection
   To apply any attack detection logic, API requests should be parsed. The complexity of API request parsing is much higher than just a one-layer of JSON, XML, or POST form. Data in fields also can be encoded by second, third, and more layer encodings, and it’s the usual case for REST and SOAP endpoints. In fact, developers define formats for each particular API endpoint they release.
   
3. Cloud native deployment method / Service-Mesh
   Yes, deployment matters. How can you use CDN-based WAF / WAAP to protect internal microservices? Same with the hardware/VM-based appliances — just not an option for the cloud-native architectures. The right option is the solution that can be deployed natively in your environments including K8s and service mesh. Ideally you would have a variety of options — module for the API gateway, or Ingress controller, or just sidecar proxy in your pods.

4. Data leakage prevention.
   Is there any endpoint that exposes data that it shouldn’t expose? Is there a way to abuse this API and with the enumeration attack retrieve all the data from the database? (This has happened to a number of companies over the last two years.) Make sure the API security solution can help to protect against leakage of the PII or any other sensitive data.
   
5. API Discovery – Up to date API Inventory — Shadow and Zombie APIs
   To have effective security, you must truly understand your API inventory and get deep insights on your APIs. Why are the vulnerable v2 and v3 still exposed if they are deprecated for almost a year? What else is exposed and you don’t even know? Are Swagger specs up to date? (Teaser: Surely not). Your API security solution should be able to give you these answers for both external and internal APIs.

When you ask people “What is API security”, a lot of folks would mention API authentication. However, API security is actually a lot about API threat prevention. Yes, you can have mTLS between microservices and you should have. But you also need to be sure they are protected against relevant threats. It’s become even more important today, in the COVID-19 times, when a lot of services, once internal, all of a sudden become exposed to everyone to support WFH effort.