DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Software Design and Architecture
  3. Integration
  4. How to Block API Runtime Threats

How to Block API Runtime Threats

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.

Ross Moore user avatar by
Ross Moore
·
Dec. 16, 22 · Analysis
Like (2)
Save
Tweet
Share
3.33K Views

Join the DZone community and get the full member experience.

Join For Free

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.

API Application security security Integration

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Are the Benefits of Java Module With Example
  • GitLab vs Jenkins: Which Is the Best CI/CD Tool?
  • How Chat GPT-3 Changed the Life of Young DevOps Engineers
  • Practical Example of Using CSS Layer

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: