APIs, or application programming interfaces, are an essential part of modern software development. They enable applications and services to communicate with each other, providing a way for different pieces of software to work together. Using APIs, a single backend service can serve a multitude of clients, including websites, mobile applications, and even other servers. According to a recent Cloudflare study, APIs have become so popular that they now drive a majority of all web traffic. 

However, as with any software component, APIs are vulnerable to security threats. In fact, a recent report states that 41% of organizations had an API security incident in 2022. Of those, 63% noted that the incident involved a data breach or data loss. Hackers can exploit vulnerabilities in APIs to gain access to sensitive data, disrupt services, or even take control of an entire system. Therefore, it is imperative to secure APIs in order to protect them against such threats. 

Most organizations need an application security strategy, but that is often easier said than done. It can be hard to find people who are trained in security, so many organizations must teach these skills on the job. By making the security of your products more visible to developers, you help them no matter their skill level. Whenever a vulnerability is found, focus on learning instead of blaming. Also, why not put the latest security scan outcomes on a screen in the break room?

In this blog post, I’ll describe four steps to take your API security to the next level.

Make an Inventory

Let’s start at the beginning: make an inventory. This is more important when working with APIs compared to other assets because they are often hidden. As always, you can’t protect what you don’t know you have. And it’s not always obvious that an API was involved in delivering functionality to an end user! We have also seen endpoints left over from the development process that someone forgot to remove. Inventory should be a core part of any business process and tools like automated API discovery can assist.

Become Familiar with the OWASP Foundation and the ASVS

A great resource for application security is the OWASP Foundation which, among many other things, maintains the Top 10 awareness document for web apps. This document is essential reading for all web developers, but there is also a lesser-known counterpart for API security. These lists of common vulnerabilities are important to understand because they include common mistakes that appear again and again across the whole industry, independent of what framework and language is used. Basically, they capture the fact that security is quite boring, no matter what the headlines say. Preventing, detecting, and stopping attacks has more to do with good security hygiene (the “boring” stuff) than whatever the latest flashy vulnerability the headlines talk about. The Top 10 lists are useful learning tools, but are not actionable for development teams. For that, you should look at another OWASP project: the Application Security Verification Standard (ASVS). This project gives developers several pass/fail criteria that they can compare their APIs against. The ASVS can also adapt to different needs, depending on the desired security level of the application:

• Level 1 is for low assurance levels and can protect against the most basic attacks.
• Level 2 is the most common level and requires effective security controls to be in place.
• Level 3 is reserved for the most critical applications and requires more in-depth testing than the lower levels.

Embed Pentesting

The ASVS leads us straight into the next essential element of API security: penetration testing. Bringing in an expert makes it possible to be thorough and uncover issues that are hard to find in other ways. According to the ASVS, automated tools are highly encouraged, but not enough. The different levels put different requirements on the testing phase. In theory, an ASVS Level 1 application can be tested in a black box fashion, while the other levels require more information, such as documentation, source code, configuration, etc. Still, it is always recommended that testing is performed with as many resources as possible. Also, the value of a pentest depends on how well the test is managed. Are testers given the correct scope? Do they have enough time to complete their tests? How about documentation?

Utilize Security Scanning Tooling (SAST and DAST)

My final recommendation is to use tooling for security scanning. An API is defined through something called a schema. This is a machine-readable text file that describes all endpoints, what methods they support, what data they expect, and how data is returned. This schema is either defined before the application is developed or can be generated after the fact. In any case, if you study the schema, you might learn things about your application that you didn’t know. Perhaps there are some endpoints you missed in the inventory step or you notice that a status code is set to the wrong value. These are just some of the security-related findings you can make. Studying the schema manually can be tedious, so be aware that there are tools to help you work more efficiently.

Next, it’s time to perform security scanning and we recommend starting with static application security testing (SAST). This is an inside-out test that analyzes your source code. It helps ensure that you are calling your methods the right way, that you configure your framework correctly, and that you can check internal data flows. SAST can and should be performed early. We recommend that you start when you are writing the first line of code. By testing early, you catch bugs when they are easy to fix and you haven’t fully cemented your architecture. SAST is especially good at finding injection attacks.

As soon as your application can run on its own, you should add dynamic security testing (DAST). This testing is outside-in. It sends specially-crafted requests to your API and checks the response, simulating different types of attacks. DAST is a holistic test across your whole ecosystem. It is good at finding authentication bugs from both the OWASP Top 10 and the API Top 10. Keep in mind that a DAST scanner will need the API schema we previously mentioned, so make sure you have that ready in order to start the scan.

Don’t forget to leverage any existing tools you might have. Are you serving your APIs through a cloud provider? Then make use of the security features you already pay for. Rate limiting, web application firewalls, audit logging, and strong authentication are just some features that come to mind here.

Penetration testing gives the best coverage, but it’s expensive and takes a long time. Therefore, it’s important to have your testers focus on the most important part of the application. Your automated security scans will help you find and fix as much as possible before the pentest even begins. If you are using high-quality scanners, they will integrate SAST and DAST to your IDE, enabling developers to get immediate feedback on improving the security of their code. Remember: No tool can fully replace a penetration test, but it could allow you to do full tests less often and save you money.

In Summary

Securing your APIs can be a long journey, but the best way to start is taking the first step. This blog post gives you many starting points to consider. Do you know what APIs you have and who owns them? Are you following a methodology such as the ASVS and are you doing penetration testing right? Sophisticated security scanning tools like those in our Fortify portfolio help you do automated tests and integrate easily into a DevSecOps workflow, allowing you to release early and often with confidence.

Are you interested in learning more? Download the free Developers guide to API security.

This article was submitted by OpenText Cybersecurity.