API Security – Crafting an Effective Strategy

Let’s start with the basics.

API security refers to the strategies, protocols, and tools implemented to protect application programming interfaces (APIs) from unauthorized access, misuse, or malicious attacks, ensuring the confidentiality, integrity, and availability of data they handle and the services they enable.

API breaches and incidents cost companies up to $75 billion in 2022, with an average cost of $4.35 million PER BREACH.

And that’s before fines or penalties, which can be as high as $1.19 billion.

This alone highlights the huge scale of the problem industry-wide, but the risk to your company doesn’t stop there.

A breach containing personally identifiable information (PII) directly affects your customer’s security and safety. Which can often (and rightfully) have huge legal consequences.

But the risk doesn’t stop after the initial breach.

Now, with widely publicized zero days like the infamous Log4J vulnerability, a bad actor only needs to get one payload in, and they have the key to your infrastructure.

They can then access your databases and internal systems, install ransomware, etc, and you wouldn’t even know.

All of this combined could not only destroy your reputation, but possibly your entire business.

This is why API security needs to be at the core of your security strategy.

You want to have well-secured APIs and applications, so you can sleep soundly at night, confident in your business continuity.

This means clear observability over your APIs, where you know exactly what’s going on. If you don’t know which APIs you’re using or what they should be doing, you won’t know when something bad is happening.

But getting to this level of security and observability can feel impossible, and it’s hard to know where to start.

That’s OK, though, because we know exactly where to start. And in this guide, we’re going to break it down for you.

In this article, we’ll cover:

• The importance of securing your APIs
• Common pitfalls when implementing API security
• Breakdown of the various parts of API security

More than just ticking boxes

With APIs making up 83% of all web traffic, API security has to be an important part of any security strategy.

They’re a key component in nearly all modern mobile and web applications, and they’re designed to be accessed by third parties. Which exposes them to a wider range of attackers than traditional web apps.

And they often have more attack surface area than a user interface.

But often API security is seen as simply a box-checking exercise. With companies mostly focusing on being compliant with things like HIPAA or SOC2, because they legally have to be.

This becomes the single objective, rather than actually securing the APIs, managing risks, or having actionable observability.

It’s like a car manufacturer installing a piece of string, so they can check the box next to “Seat belt”.

Have you technically done the thing? Sure. But it’s not making anyone safer.

Another big reason for companies not taking API security seriously is the cost. It’s an unavoidable reality that cybersecurity is expensive.

According to Statista, companies worldwide allocate at least 12% of their IT budget to information security. This adds up quickly, and as more and more threats emerge, it’s increasingly difficult to prioritize the budget.

So instead of looking for the right solutions, it’s easier to look for the cheapest and simplest solutions.

But even if you’re sitting on a big pile of cash labeled “API Security Budget”, it’s useless without a security-first culture within your business.

So many companies will acknowledge the importance of API security but don’t have anyone in place to champion the improvements, tools, and processes needed.

To implement these necessary measures, you need to have strong security leaders and an executive team that has confidence in them.

People who can educate the rest of the company, put in the time and research, and implement the API security measures.

Without this, it just won’t get done. It can’t, because everyone has their own priorities, and things like this quickly slip down the list.

Until there’s a breach…

It’s such a cliche that it’s become a running joke in the industry.

Companies won’t invest in API security measures until they’ve been breached, and it’s too late. And it happens all the time.

Companies skimp on API security, then get hit hard with a breach. This means all at once you have the cost of the breach AND the cost of implementing new API security measures.

It’s amazing how quickly your security budget can jump up once you’ve made the news, and had to issue an apology to customers.

That’s not to say spending big guarantees immunity, though.

It’s unlikely that a huge company like T-Mobile skimps on its security budget. Yet they’ve been breached EIGHT TIMES since 2018

This resulted in a $350 million class action settlement in 2021, that included a commitment from T-Mobile to spend an additional $150 million to improve their cybersecurity.

Then in January this year, they were breached again, impacting approximately 37 million of their customers.

And do you want to guess how the bad actors got access this time?

That’s right! Through their APIs.

This isn’t a one-off, either. Big names like Facebook, USPS, Equifax, Venmo, and Equifax have all experienced high-profile API breaches in the past.

All of which highlights how much more can be done to improve API security across the industry, at every level.

Three pillars of API security

The secret to API security isn’t just with one approach or one tool. 

(If you were limited to one tool, though, we’d strongly recommend ThreatX)

It’s about having multiple layers to your defense. Depth, that spans three cybersecurity pillars:

• Prevention: What can you do proactively to stop security breaches?
• Detection: How do you know when a breach has occurred
• Response: What can you do to stop an active breach, and minimize the damage?

A lot of the concepts will have overlap and crossover between these pillars, but we’ve organized them this way to make it easier to process and plan.

Prevention

Prevention is all about proactively planning for potential threats and risks in your API.

When you’re writing code, you need to include safeguards, and you want your CI/CD environments to be configured to be as robust as possible.

If your data is money in a bank, then this would be the walls, the locked doors, the vault, etc.

Basically, you’re making it as hard as possible to breach your API in the first place. Which includes a number of things.

Authentication & Authorization

A big part of prevention is ensuring only the right people can access the right information. You do this with authentication and authorization.

Authentication is all about determining whether someone is who they say they are. This is most commonly done using an API or authentication key that is sent with the request.

Whereas authorization is about whether or not that user should be able to access a certain resource or carry out a specific action. This is managed by configuring and managing different permissions for different users.

This combination of authentication and authorization gives you the ability to know who’s trying to access the API, and decide what they can and can’t do. 

Encryption

Another way of preventing unauthorized access to your data is by encrypting it. This is the process of encoding your data, so only your authorized users can access and read it. 

This is commonly achieved using HTTP or TLS protocols, which create secure communication between the user and the source. So even if a bad actor manages to intercept the data, they won’t be able to read it.

Threat modeling

In order to make better decisions to protect your API, you need to have a clear idea of existing and potential security risks

Threat modeling is a structured way to identify and evaluate these risks. The end result of which is a clearer understanding of your API, so you can safeguard against these risks both in your API design and configuration.

API gateway

Sitting between a client and one (or many) APIs, an API gateway secures traffic between an API request and the execution.

This includes things like the authentication and encryption we’ve already talked about, rate limiting, and transaction logging.

In a nutshell, it’s a piece of software that provides an extra layer of protection for your APIs.

Training

To achieve a high level of API security, you need a high degree of security literacy, especially among developers.

Security awareness training is a great way to do this, as it teaches your team to think about security at different levels.

They need to know how to include things like input validation to prevent SQL injection, for example. They also need to know how to do security testing, and identify vulnerabilities in their configuration and code.

And if they’re using external libraries or code they found on Stack Overflow, they need to know how to make sure it’s safe to use.

This training will also span across detection and response, as you want your team to be able to efficiently detect threats, and respond accordingly.

Detection

Observability is the name of the game here—whether something bad is happening or not, you want to have visibility over the constant flow of information.

Ideally, you want to achieve this level of visibility from one place. One tool where you can view all of your security data, and correlate the different events and issues across the environment.

This becomes your single pane of glass that you can look through to see everything, organize the data, and identify anomalies.

Without this, it’s impossible to prioritize and make informed decisions.

Going back to the money in the bank metaphor, this is the cameras, sensors, and Jerry the security guy.

You want to have as clear a picture as possible of what’s happening, so you can decide whether you need to call the police or simply adjust a sensor.

Logging

If you’re going to detect anything, you need to have a clear view of what’s happening on your API. Logging is the foundation of this, by capturing all the events that occur.

This is agnostic to good or bad, it just creates a clear record of everything going on. Every call to the API, every error, every failure, etc

Monitoring

It’s all well and good capturing all this data, but you need to be monitoring it to get value from it. 

Did someone just try to authenticate to your API without permission? That’s unusual behavior you’ll want to know about.

You’ll want to have alerts set up to flag these things, so you know about it straight away and can decide if a response is required.

Rate limiting & behavioral detection

Straddling the line between detection and response, rate limiting and behavioral detection are important for securing the requests coming into your APIs.

Rate limiting restricts the number of requests an API can process, regulating legitimate users while protecting against malicious attacks.

And behavioral detection uses machine learning to monitor API traffic, scrutinizing the behavior of its users.

It does this by tracking and analyzing the traffic metadata, including things like error rates, user identity, activity, and more. Identifying concerning behaviors:

• Anomalies: Behavior that’s unexpected, but not necessarily good or bad 
• Signature-based: When behavior matches the patterns or signatures of known attacks or attackers 
• Attacker-centric: Anomalies or signature-based behaviors that correlate over time to indicate the likelihood of an attack

The goal for identifying and categorizing these behaviors is to identify threats as quickly as possible, so they can be evaluated and—if necessary—stopped.

Response

The first two pillars directly address proactively stopping an attack, and being able to know what’s going on.

But you also need to know what to do when an attack has been detected. You need to quickly identify, contain, and remediate the threat as quickly as possible.

And not just that, you also want to do it meticulously, without just shutting everything down.

You want to use a scalpel, not a shotgun—identifying an attack and shutting down the bad guys, while continuing to provide continuous service to everyone else.

So if someone has broken in to steal that money in the bank, you want to stop the robbers from getting to the money, without stopping everyone else at every bank from accessing their money.

Incident response plans

When something happens, it’s important for everyone to understand how to react. You need procedures and plans to figure out what to do next.

Sometimes this will be simply letting a tool like ThreatX do its thing.

But other times you might need to look at the data, send it to another tool, or make a decision.

Instant response plans do a lot of the heavy lifting in these situations, as they help you to know what decision to make, and what information you need to make these decisions.

Automatic blocking

It’s good to be able to jump on these issues and fix them as quickly as you can. But it’s much easier if you remove that manual step.

If you use a tool like ThreatX, then once a threat is detected, it’ll automatically block it in real time. This brings detection and response together, and mitigates risks as they are identified

Threat intelligence

An important part of responding to threats and attempted breaches is being able to clearly understand the attacker’s motives, their attack behaviors, and what they’re targeting.

By understanding this, you can mitigate further attacks, and identify ways you can improve your security.

For example, when a new zero-day vulnerability is identified, you need to respond to the new information quickly and proactively

When the Log4J vulnerability we mentioned earlier came to light, we implemented protection for our ThreatX customers in less than an hour.

Without this kind of threat intelligence, you’re opening yourself up to a world of hurt!

API Security Checklist: 5 Standards for Protecting APIs

You can break it down into a simple five step checklist, and to help you remember those steps, we have made these steps rhyme too.

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. 

API Security vs Application Security

Often confused and used interchangeably, these two terms are entirely different. They have more of a parent-child relationship.

API security focuses on safeguarding the interfaces through which applications communicate, ensuring they are protected from unauthorized access, misuse, and malicious attacks.

Application security, on the other hand, encompasses a broader set of measures aimed at ensuring the entire business applications – including its source code, functionality, and execution environment – is free from vulnerabilities that could be exploited.

While both are integral to a business, API security emphasizes interconnectivity, whereas application security is more of a holistic approach to security.

In closing

API breaches can cost companies billions of dollars, making API security a crucial aspect of any organization’s security strategy.

But by focusing on the three pillars of API security, you and your company can get ahead of these threats, and protect your data as much as possible:

• Prevention
• Detection
• Response

Your API security will no longer just be a box-ticking exercise, and you’ll achieve better observability over your APIs, safeguard against potential security threats, and be prepared when issues or threats do arise.