Securing application programming interfaces (APIs) and the data they expose has become a top priority for organizations. This guide provides an overview of API security, with a focus on ways to automate API security testing in a continuous process.
API security covers all the security tools, processes, and controls involved in protecting systems, data, and organizations from threats targeting APIs—application programming interfaces. Unlike graphical user interfaces, APIs are intended for automated data exchange with external systems and between internal application components. When looking at APIs as an extension of the visible application attack surface, three core areas of API security are crucial for securing applications:
API security is a broad field that covers other areas and tool categories as well. To name just two, API posture management (also called classification or categorization) involves labeling API endpoints to help with remediation for new vulnerabilities. Another common concern and a vital part of API security strategies is API access control, which involves defining specific user and application access rights to APIs to give security more control over what is accessed and exposed.
APIs provide a less obvious way for attackers to access sensitive information from applications. Instead of breaking in through the user interface, threat actors often prefer to look for an unprotected side door, making APIs a first-rate target and a source of major data breaches, including many that have exposed personal data. Considering the millions of IoT (Internet of Things) devices that use web APIs to receive commands, return data, and perform operations, API attacks can also allow malicious hackers to compromise physical security measures and exploit insecure internet-facing devices as entry points to pivot into internal systems.
There are at least five high-level reasons why API security has become so important for organizations:
API security is a subset of overall application security and is critical for protecting modern applications that rely on web services and APIs for data exchange with systems and users. Applications designed using microservice architectures go a step further and are entirely built from services that rely on API calls not only for external communications but also for internal data interchange.
One important difference is that API traffic is almost entirely automated, allowing for request volumes that you would rarely get from manual user interactions with a web application GUI. This enforces different requirements compared to “regular” application security and makes extensive automation a non-negotiable aspect of any effective API security program. This goes doubly for backend APIs, where many systems, services, and applications can rely on the same API to operate—including most mobile applications.
An API can be any way to programmatically access application data and functionality, including completely custom implementations, but most organizations tend to go with one of several common API types (in order of popularity based on a 2023 report): REST, SOAP, or GraphQL. While the network-level security measures will depend more on application architecture than API type, application-level API security differs significantly across API architectures.
REST APIs are by far the most common API type, used in over 85% of organizations that work with APIs. REST (REpresentational State Transfer) is not a strict protocol or format but an architectural style for building web applications and services. With REST, HTTP protocol methods are used as operation types, and JSON is the most common data format.
Because each operation exposed by the API needs its own endpoint and URL, REST APIs are major contributors to the overall attack surface, especially since REST requests can be very predictable. When a new API spec is published, the old and new versions typically coexist for a time to maintain compatibility for existing API consumers. Forgotten APIs that are left in production indefinitely are a common attack vector in REST API security, sometimes requiring only a change from v2 to v1 in the URL to access a less secure version of a production API.
SOAP (Simple Object Access Protocol) was the “original” web API format and remains in use today, especially in business applications, though it is less common than REST. Unlike the loosely-defined REST style, requests in the XML-based SOAP API type have to strictly conform to a predefined schema, making them less convenient for simple operations and especially for frequent changes during rapid development.
Being specifically designed as an enterprise API format, SOAP is generally considered more secure than REST, especially as it includes some built-in features for error handling and encryption. SOAP requests must also strictly follow the XML schema defined for the API, making them harder for attackers to spoof or imitate (though also harder to test).
Where REST and SOAP are general-purpose API types, GraphQL is not so much an API format as a specialized data query and manipulation language for database access APIs. Although a relative newcomer compared to REST and SOAP, it is quickly gaining popularity, being used by up to 30% of API developers.
Instead of multiple endpoints per API like REST, GraphQL usually only uses a single endpoint to receive queries and return data, which can simplify traffic routing and security testing. It also has some built-in features for validation and type checking. At the same time, GraphQL security comes with its own challenges, not the least of which are second-order vulnerabilities. It’s common to implement a GraphQL layer to unify existing REST APIs, making it an indirect target for injection attacks against those underlying APIs.
While APIs are often talked about as separate entities, the very name “application programming interface” is a reminder they are only an intermediate layer of access to some underlying system or application. Any discussion of API vulnerabilities needs to consider two levels of security:
OWASP (the Open Web Application Security Project) maintains several top 10 lists related to web application security, with one of the more recent being the API Security Top 10. If your applications expose API endpoints, you need to incorporate API-related security risks into your overall cybersecurity strategy. Listing the most impactful risks is the stated purpose of the API Security Top 10, so the list should be treated as an aid to secure design for API development and API security controls, not as an explicit API vulnerability checklist.
OWASP API Top 10 for 2023
As with all OWASP top 10 lists, it’s useful to look for broader strategic themes. At a high level, the major API security risks can be grouped into five broad categories:
Automated dynamic application security testing tools are the natural choice for probing the entire attack surface of an application, both API and GUI—but very few web vulnerability scanners are mature and accurate enough to safely run the thousands of security checks required and return useful results.
As the first DAST vendor to build API scanning into its products, Invicti continues to lead the industry in the accuracy, coverage, and automation of web application and API vulnerability scanning. The Invicti platform comes with a host of features and capabilities for automated API security testing, including:
Defining and implementing effective API security policies and controls should be an integral part of your wider application security program. At the same time, some security measures are API-specific, so here are some key strategies to make sure that API security requirements are never overlooked or underestimated:
Compared to application security testing, where different testing methodologies can be used at different stages of development, and many security issues can be caught already at the source code level through static application security testing (SAST aka static analysis), the majority of API security testing needs to be done dynamically. This is because you often won’t have direct access to the underlying application or system (nor its source code), and even if you did, you still need to test for runtime vulnerabilities, whether caused by misconfigurations or complex interactions between systems in production.
A DAST-centric process and toolset for integrated application and API security testing is an effective way to systematically find and remediate security weaknesses before they can be exploited by malicious actors. To make this work in practice requires a DAST solution that maximizes coverage for discovery and testing, can test across all common web app and API technologies, and integrates deeply into the software development lifecycle (SDLC). Depending on your DevOps workflow, it should also be able to run scans automatically in a continuous process: at predefined points in the development pipeline (typically for new builds), on a business-specific schedule in production, or both.
To learn how this can be done using an integrated DAST-centric AppSec platform, read the Invicti white paper Security at the Speed of Software: DAST in the SDLC.