How to Block API Runtime Threats

Everyone wants to stop threats. They really do. No one wants someone to break into their home or car. Nobody wants to be accosted on the street. We all want a safe environment wherever we go. But we have to hope for the best and prepare for the worst (and prepare to be surprised!).

It’s the same with apps. No business wants its web or mobile apps to be under fire. It would be great if all the criminals would either honor the purpose of the apps and just leave them be, or simply not notice. 

We all know that it doesn’t work that way, but with some of the more straightforward ways that companies, even high-profile companies, have been breached, it seems that companies have been hoping for the best just a bit too much.

APIs Invite Danger

The first step in blocking any threat is being aware that there is a threat. APIs are abundant (ubiquitous isn’t quite the right term, but it’s close!), and rightfully so because they provide a tremendous amount of flexibility for orgs to connect people, apps, and services to all kinds of information, products, and other services. It’s incumbent on organizations to realize the clear and present danger that APIs present. 

This danger is why the OWASP API Top 10 exists — APIs had become such a security concern, and the attacks against them were so different from traditional web application attacks, that this project was published in 2019 to showcase the biggest threats to APIs.

Traditional security controls miss certain API attacks because “the successful API attacks don’t follow those kinds of “one-and-done” mechanisms that leverage known vulnerabilities.”

Gartner research from December 2021 states, “Enterprises are producing a massive number of APIs at a rate that far outpaces the maturity of network and application security practices.”

In March 2022, Cloudflare posted, “Due to the underlying format of the data in transit, API traffic tends to be a lot more structured than standard web applications, causing all sorts of problems from a security standpoint.”

APIs — treasure for business, trouble for security.

(API) FailArmy

Have you ever watched FailArmy? They’re videos that show people failing at various activities, such as sports and stunts. It hurts to watch when these people hurt themselves. 

It also hurts to see technical teams set themselves up to fail at protecting web-facing resources. So much time, money, and talent can be spent on activities that are extraneous to securing obvious risks such as APIs.

Let’s explore ways not to block runtime threats. These are activities and approaches that impede the ability to properly secure resources.

1. Force Developers to Fill Out Report After Report

• Documentation, change control, access control, logging, etc. are essential parts of information security. It takes a critical eye to look at all the moving parts and eliminate what’s useless or counterproductive.

2. Attain ISO 27001 Certification and a Good SOC 2 Type 2 Report and Leave It at That

• Attestations are great achievements and something to celebrate and provide businesses good reasons to maintain good security. But they only provide the framework and some best practices. There are many details that are not included, including numerous other technical details that need to be considered and deployed by internal SMEs.
• It’s interesting to note that the new version of ISO 27001 — released October 25, 2022 — includes new controls such as threat intelligence, data leakage prevention, and secure coding.

3. Always Create New APIs…

• …While never replacing the old ones. API sprawl, which leads to zombie and shadow APIs, will leave old APIs alone and forgotten. And that means they will be easy targets for threat actors to find and manipulate.

4. Alert on Everything…

• …so that the SOC analysts (or equivalent) are worn out from alert fatigue. Monitoring and alerting are important aspects, but if the metrics are simply the number of alerts attended to instead of the quality of alerts handled, then the company is asking for trouble from analyst burnout and turnover.

5. Always Meet About the Products and Services…

• …instead of actually developing the products and services. The more meetings that take devs/engineers/QA away from truly working on the products only reduces the true quality of the UX and security. 
• A corollary issue is burdensome training. Training is necessary because of the constant flux in the software ecosystems, but training should enhance, not hamper, production. It’s the “sharpen the saw” idea.

Positive Actions

Here are some specific actions to take to protect runtime APIs. I’ve selected three highly targeted API vulnerabilities from the OWASP API Top 10 list.

Security Misconfiguration

Some ways to mitigate security misconfigurations are to:

• Disable unnecessary features and permissions
• Enforce repeatable hardening processes
• Automate processes to discover configuration flaws

Lack of Resources and Rate Limiting

Implement:

• API-specific rate limits on methods, clients, and addresses
• Server-side validation for query string and request body parameters
• Compression ratio checks

Excessive Data Exposure

• Never rely on the client to filter sensitive data.
• Review the API responses to ensure they contain only necessary data.
• Review any PII that is stored by and worked with the application to ensure that it’s needed.

Overall Strategy

Here are a couple 30,000-foot-view principles to help create a more comprehensive approach that can help identify and address runtime threats:

• Contextual awareness: Ensure that your team has visibility into all traffic coming in and out of their APIs as well as how they are being used by developers. This will help identify potential security risks and mitigate them before they become real threats.
• Visibility: You need visibility into all traffic coming in and out of your API, including access logs and usage data. This allows you to see what type of traffic is hitting your APIs, including requests originating from bots or other automated processes that may be trying to access unauthorized resources or use them for malicious purposes.

What’s the Right Approach?

Whatever approach one takes to secure APIs, avoid security theater. This is when security measures are taken that give a feeling of improved security but provide little or nothing to better secure the resource. 

Meet with all stakeholders — e.g., Product, Engineering, Compliance — to discover the actual risks presented. This might be tedious and seem time-consuming, but providing a good foundation for designing, implementing, managing, and maintaining the API — all based on a multifaceted array of input — will lead to responsible all-around protection of corporate assets. Customers and coworkers trust that data defenders are guarding their information, and taking a thoughtful approach is part of proving that to them.