ThreatX - Blog

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 overWebsockets). Since this topic is top of mind for manyfolksI'd like to consolidate some of the table stakes for securing public andinternalAPIs and then discuss taking API security to the next level.

Table Stakes

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

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 aservice meshto add automatic encryption on top of service discovery and routing. It's nice to know that ThreatX plays nice with service mesh architectures when using asidecar pattern deployment.

Authentication

API authentication is important to protect against XSS and XSRF attacksand 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 OAuth 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.

Authorization

Once you authenticate a user or a microservice, you must restrict access to only what is required. For example, non-adminusers 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:

Rate Limiting

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

Block Large Requests and Responses

Some attackers may try to overwhelm the APIor trigger a buffer overflow vulnerabilitywith 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.

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 beentered intoa JSON parameter within an API request body. ThreatX automatically detects and blocks this type of input abuse.

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 ThreatX NG WAF.

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 ThreatX NG WAF can thwart, whether the fuzzing is obvious or low-and-slow, viaapplication profiling andentity behavior tracking.

L7 DOS Protection

You have protected the front-end of the API with rate-limiting, but the back-end services can still be exposed toLayer 7 denial of service. This is traditionally a difficult problem to solve, but ThreatX 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 betarpittedand eventually blocked - automatically and without tuning.

Custom API Rules

You (hopefully) know your API better than anyone else and ThreatX provides a robust matchingengineso 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 theContent-Typeheader to be what is expected for your API (e.g.application/json) or block unused or non-public HTTP methods (e.g.PUTandDELETE) to further lock down the API.

Next Gen API Protection

But we can go even further than the protections above! ThreatX 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.

Threat X Labs - Blog

Arm yourself with information and insights on the latestcybersecuritytrends to defend against today's most advancedcyber criminals with articles from the leader in SaaS-based web application firewall solutions.