API Security Checklist: Top 7 Requirements

As I talk to customers around the world about securing their applications I’ve noticed a specific topic keeps coming up more and more often: Securing their APIs – both public and internal varieties. RESTful JSON APIs seem to be the most prevalent these days, but I still hear about SOAP and XML APIs, as well as some customers on the bleeding-edge with GraphQL APIs they want to protect. 

The nice thing about modern APIs is that, in most cases, they can be protected very similarly to how we protect regular old web applications since they really are just applications that run over HTTP (and sometimes over Websockets). Since this topic is top of mind for many folks I’d like to consolidate some of the table stakes for securing public and internal APIs and then discuss taking API security to the next level. 

Table Stakes 

If you are building an API for public consumption or even only for your internal microservices then there are a few things that need to be done even before considering any additional security layer or technology: 

1. Encryption

SSL/TLS encryption is mainstream and should be used for both public and internal APIs to protect against man in the middle attacks, replay attacks, and snooping. For external APIs the web server can handle this directly or a reverse proxy can be employed.  For internal APIs libraries can be used or consider using a service mesh to add automatic encryption on top of service discovery and routing. It’s nice to know that Threat X plays nice with service mesh architectures when using a sidecar pattern deployment. 

2. Authentication

API authentication is important to protect against XSS and XSRF attacks and is really just common sense. Typically, the username and password are not passed in day-to-day API calls. Rather, an API key or bearer authentication token is passed in the HTTP header or in the JSON body of a RESTful API. Tokens should expire regularly to protect against replay attacks.  Most enterprises will use an internal database or LDAP authentication store, though Oath may be an option for highly public APIs. 

Client-side authentication can also help lock down your API, if appropriate.  By using client certificates and certificate pinning in your application you can prevent man-in-the middle attacks and ensure that only your application can access the API. 

3. Authorization

Once you authenticate a user or a microservice, you must restrict access to only what is required. For example, non-admin users may only need read-only access, not the ability to create, update, or delete records. This is typically best handled by application logic, but it is possible to farm this functionality out to an API gateway. 

Beyond the Minimum Requirements 

Ok, let’s talk about going to the next level with API security. Once you have the table stakes covered it may make sense to look at a Next Gen WAF to provide additional protections, including: 

1. Rate Limiting

Especially important if your API is public-facing so your API and back-end are not easily DOSed. Simple rate limits are available in many web servers and proxies, though more sophisticated entity intensity tracking is even better. Threat X tracks the intensity of requests coming from each entity and can throttle an entity if their intensity significantly exceeds other users accessing the API. 

2. Block Large Requests and Responses

Some attackers may try to overwhelm the API or trigger a buffer overflow vulnerability with large requests. These may be in the form of a large JSON body or even unusually large individual JSON parameters within the request. Also, an abnormally large response may be and indicator of data theft. NG WAF allows the creation of custom rules to track and block these suspicious requests. 

3. Input Validation

It is common to see SQL Injection attacks on standard web applications, though these and other input abuse attacks can be carried out against APIs as well. For example, SQL, PHP, xpath/xquery, LDAP DN/LDAP Query, BASH Script, JavaScript or other code can be entered into a JSON parameter within an API request body. Threat X automatically detects and blocks this type of input abuse. 

4. Geofencing

If your API is public, it might make sense to either block users from countries you don’t do business with, or at least raise the risk score of entities that come from those countries. This is a basic feature of the Threat X NG WAF. 

5. API Fuzzing Protection

You may have a combination of documented and undocumented features in your APIs. Attackers may attempt to map and exploit the undocumented features by iterating or fuzzing the endpoints. This is something the Threat X NG WAF can thwart, whether the fuzzing is obvious or low-and-slow, via application profiling and entity behavior tracking. 

6. L7 DOS Protection

You have protected the front-end of the API with rate-limiting, but the back-end services can still be exposed to Layer 7 denial of service. This is traditionally a difficult problem to solve, but Threat X has a unique L7 DOS protection feature that utilizes data from application profiling to determine if requests are taking significantly longer than normal to return. An entity that continues sending long-running queries will be tarpitted and eventually blocked – automatically and without tuning. 

7. Custom API Rules

You (hopefully) know your API better than anyone else and Threat X provides a robust matching engine so you can build your own business logic rules.  

For example, a simple protection might be to identify your authentication token (in the HTTP header or in the JSON body) and require it to always be present to block and log any unauthenticated attempts.

Another example would be to enforce the Content-Type header to be what is expected for your API (e.g. application/json) or block unused or non-public HTTP methods (e.g. PUT and DELETE) to further lock down the API. 

Next Gen API Protection 

But we can go even further than the protections above! Threat X is currently working with our customers to provide even more advanced API protections that you’ll be hearing about soon, including deeper API profiling and more automatic mitigations that don’t require custom rules, and enhancing our Active Deception technology to support APIs.  

Do you need to protect a public or internal API at scale? We’d love to help and do a deeper-dive into our unique capabilities.