API Security Checklist: 5 Standards for Protecting APIs

These days, it seems like every conversation I have–with friends, colleagues, prospects, or customers–comes back to APIs! How to secure APIs, how to write and deploy APIs; how to manage APIs; and how to instantly protect APIs from the explosion of sophisticated attacks against them.  

RESTful JSON endpoints are ubiquitous. They’re the building blocks of modern web infrastructure. Tried and true design patterns like SOAP and XML APIs still implement massive amounts of business logic and move massive amounts of sensitive data in nearly every enterprise. And bleeding edge technologies like GraphQL and gRPC promise powerful and flexible new features, driving adoption by front-end, back-end, and full-stack developers alike. 

Whether we’re talking about publicly exposed first-party APIs, “internal” APIs in a microservice mesh, or third-party APIs used to integrate systems and DevOps workflows, the mandate for security professionals is the same:

Secure the APIs. 

Since API Security is top of mind for so many folks, I thought it would be good to get up on my soap box, and share my opinions about what’s table-stakes for a robust API security platform.   

I break it down into a simple five step checklist, and to help you remember those steps, I made them rhyme: 

1. Protect 
2. Detect
3. Inspect
4. Reject
5. Reflect

Step 1: Protect your APIs with instant threat protection

This is API Security 101. It’s table stakes for your API security program.  

Irrespective of provenance, irrespective of tech stacks, irrespective of deployment methodologies, if you have publicly exposed APIs, your best first step is to put proactive real-time inline protection in place.  The nice thing about modern APIs is that, in most cases, they can be protected the same way we protect regular old web applications.  Remember, for the most part, APIs are really just applications that run over HTTP.  There’s a number of ways to do this, and I have an editorial opinion about which way is best (hint: There’s a reason ThreatX is named a visionary in Gartner’s 2021 WAAP MQ).  

But no matter what approach you choose, this is your first step. Protect your perimeter.  Protect your APIs from attacks.  

Do it today.

Do it NOW.

Step 2: Detect and discover all your API endpoints

Our customers routinely report that they have way more API endpoints getting traffic than they thought. This sounds crazy, right? But it’s common.   

For starters, developers do things… They deploy dark API endpoints to support future functionality. They do canary deployments, and sometimes leave old versions of APIs deployed for backward compatibility. And they sometimes bypass even the best-intentioned security testing programs in the interest of time-to-market. 

So Rogue and Zombie APIs are common problems. 

The best mode of discovery for API endpoints is real-time analysis of the actual traffic hitting those endpoints. Ever the visionary, that’s how we attacked this problem at ThreatX.  

We’ll show you what’s actually getting traffic, so you can tighten the perimeter protection around risky endpoints or track down those workloads and deprovision your zombie APIs, double-tap style. 

Step 3: Inspect your cataloged APIs

Once you have a handle on what API endpoints are serving responses, take a hard look at what’s deployed and exposed, and compare your actual attack surface with your theoretical API inventory.  

For RESTful JSON endpoints, you can easily generate an Open API 3.0 schema file, from your CI/CD pipeline, that will define in excruciating detail what is and isn’t expected.  

Our Open API schema support functionality compares what your build system thinks is out there with what’s actually out there, allowing you to quickly pinpoint undefined or unspecified functionality. 

Step 4: Reject traffic hitting unauthorized APIs

Any traffic hitting endpoints you’ve identified as verboten, kick it to the curb! You may make somebody’s pagerduty alarm go off, but that’s great signal about the fact that they have endpoints deployed you don’t know about…  😉  

Our API Schema support gives you a great foundation for very specific protections of your APIs.  You can prohibit traffic with unsupported methods and keys. You can use our flow-based rules to require that your API users hit endpoints in a specific workflow unique to your business logic. Something as simple as requiring a Get before you enable a Put call can prevent myriad bot attacks. You (hopefully) know your API endpoints better than anyone else and ThreatX provides a robust matching engine so you can build your own business logic rules, and thwart attempts to bypass that business logic, by blocking traffic that violates the business logic you define. 

You can build in protection for your auth endpoints: 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.  

In addition to straight-out blocking requests, you can slow them down. Rate Limiting is especially important if your API is public-facing so your API and back-end are not easily DDoSed. 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. 

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. NGWAF/WAAP allows the creation of custom rules to track and block these suspicious requests. ThreatX lets you block large requests and responses, further protecting your endpoints from attack 

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 geofencing is a basic feature of the ThreatX WAAP platform. 

API DDoS Protection 

As a practitioner, I can tell you in all honesty that I’ve had customers actually DDOS my APIs in the past, simply by automating a query to poll for results of a long-running process.  It doesn’t take too many times through a tight loop for such an innocent-looking API integration to overwhelm database locks and bring down a back end. And that’s the innocent use case. Imagine a hacker using that same functionality to harass, harry and harangue your infrastructure. Not cool. It’s possible back at Step-1 to protect 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 ThreatX has a unique L7 DDoS 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. 

Virtual Security Patches 

Modern protection platforms provide managed services or rapid response to new CVEs or common vulnerabilities findings and can reverse engineer the vulnerability from the patch and craft a virtual patch rule to address it. For closed source applications, working proofs of concept are leveraged for protection validation. 

These API specific blocking actions further protect your API endpoints, giving you time to take a step back and think about security in depth: 

Step 5: Reflect on broader API security in depth

This final step is crucial. You’ve bought yourself time. Use it wisely. Get your AppSec house in order, to ensure security in depth. 

Take a step back and think about your overall security posture in the context of your SDLC. 

Once you have inline protection in place, you’ve basically bought some time to get at the serious business of remediation – fixing problems in your APIs.  

Defensive coding practices and secure design are critical components of a comprehensive security-in-depth program. For starters, let’s make sure you’re covering the basics. 

API Encryption 

You’re using strong ciphers, right? 

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 ThreatX plays nice with service mesh architectures when using a sidecar pattern deployment.  

API Authentication 

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

API 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. 

Public APIs should never be subjected to uncleansed traffic from the big-I internet. 

Whether you’re an app owner or work in operational security, the last thing you need is another tool to learn how to use. You need help. 

Help with all 5 API security steps, from one great company 

At ThreatX, we have long understood that an effective security offering is one that reduces, not increases, operational workload for thinly stretched OpSec staff. That’s why all our customers benefit from the ThreatX SOC, as a standard part of every customer engagement.  

We’re a security company. We get web tech. We pay attention to new 0days, we watch traffic patterns. We continuously monitor the evolution of sophisticated attacks, and we stay ahead in the perineal cat and mouse game that is cyber defense. 

Plus, we’re really good at ThreatXing. So, with our solution, you get great tech and the great team that stands behind it. 

ThreatX is currently working with our customers to improve their API security posture by providing even more advanced API protection capabilities 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.