What is API Security? A comprehensive guide to API security

What is API Security?

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 discovery: By identifying the internal and external APIs they are using and exposing, organizations can build a more complete picture of their attack surface. Popular API discovery methods include crawling for specification files and endpoints, integrating with API management tools, and monitoring API traffic.
• API security testing: Once API endpoints are known, they can be tested for vulnerabilities manually and through automated scanning. While manual API testing used to be the norm, the huge numbers of endpoints and parameters involved mean that advanced dynamic application security testing (DAST) tools are now commonly used to automate much of the testing.
• API protection: Most organizations will use an API gateway to route API traffic through a single system that puts multiple security measures between an API and potential attackers. Protection features can include load balancing, rate limiting, and a web application firewall (WAF) to provide real-time API traffic filtering. 

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.

Why is API security important?

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:

• Protecting sensitive data: APIs often serve and process personal, financial, and business data. A breach can expose sensitive information, including personal data, leading to financial losses, reputational damage, and regulatory penalties for companies while also putting individuals at risk of identity theft.
• Securing an increased application attack surface: APIs are designed to expose application functionality and data to the outside world. Without proper security, API endpoints originally intended for use by legitimate applications can become entry points for attackers.
• Mitigating advanced and high-intensity attacks: Because APIs are designed for automated access, they are specifically targeted in many high-intensity application attacks, from injection attacks and massed credential stuffing to distributed denial of service (DDoS). Strong API security measures can prevent or mitigate these potentially devastating attacks.
• Ensuring regulatory compliance: Data protection regulations such as PCI DSS, HIPAA, and GDPR mandate strong security measures for all systems handling sensitive information. This makes implementing and demonstrating solid API security a vital step to ensure compliance.
• Maintaining business continuity: Depending on the application architecture, APIs can directly support or perform critical business operations across multiple systems. For this reason, an API security breach can pose a far greater threat to business continuity than other attack avenues, with the potential to severely disrupt services, impact revenue, and erode customer trust.

What is the difference between API security and application security?

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.

What is the difference between REST, SOAP, and GraphQL API security?

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 API security

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 API security

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).

GraphQL API security

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.

What are the main types of API vulnerabilities?

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:

• Vulnerabilities in the API: The interface should only pass valid and authorized requests to the backend application. If attackers manage to compromise API protections, they can bypass or break authorization, obtain API access, and make malicious requests. Common API vulnerabilities include weak or unprotected API keys, broken authentication, failure to enforce HTTPS for all API traffic, and inadequate rate limiting that allows for DDoS (Distributed Denial of Service) attacks.
• Vulnerabilities in the backend application: Attackers treat API endpoints as merely another application entry point to probe and attack. After bypassing or overcoming API-level protections, malicious hackers can target a vast array of security vulnerabilities through API calls, including common injection attacks like SQL injection, command injection, and cross-site scripting (XSS). In the API context, SSRF (server-side request forgery) vulnerabilities can be especially dangerous by allowing access to internal systems that weren’t expected to be publicly available.

OWASP API Top 10 security risks

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

• API1:2023 Broken Object-Level Authorization
• API2:2023 Broken Authentication
• API3:2023 Broken Object Property-Level Authorization
• API4:2023 Unrestricted Resource Consumption
• API5:2023 Broken Function-Level Authorization
• API6:2023 Unrestricted Access to Sensitive Business Flows
• API7:2023 Server-Side Request Forgery
• API8:2023 Security Misconfiguration
• API9:2023 Improper Inventory Management
• API10:2023 Unsafe Consumption of APIs

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:

• Access authorization and user authentication: Most API-related breaches result from unauthorized access at the level of objects (broken object-level authorization, aka BOLA), object properties, or application functions (broken function-level authorization). Closely related are authentication failures, with broken authentication mechanisms putting apps at risk of sensitive data exposure via unauthenticated API access.
• Access control and limiting: APIs are designed for automated use, so all API access needs to be carefully managed to control security threats related to malicious API requests sent in bulk. Risks include server resource exhaustion, mass data exfiltration, and abusing API functionality through brute-force enumeration and similar methods.
• API inventory management: If you unknowingly still expose old versions of endpoints or whole APIs, you are giving threat actors an easy starting point and increasing the risk of unauthorized access. The best practice is to know, track, and document all your APIs and endpoints, whether private or public, though few organizations can claim to do this successfully.
• Security misconfigurations: Missing or misconfigured security headers and other configuration-related security issues are a common source of risk for web applications and APIs alike. They are especially dangerous because they can leave APIs vulnerable at runtime even if the code itself looks secure.
• Unfixed application vulnerabilities: APIs are just another entry point for attackers, so API attacks are often part of a bigger application attack against specific security flaws. While many common vulnerabilities can be targeted via APIs, SSRF vulnerabilities are especially useful for attackers as they can turn an API into a URL manipulation tool for accessing remote resources.

API security testing with DAST

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:

• REST, SOAP, GraphQL, and gRPC API definition support for importing and testing
• Multi-faceted endpoint and definition discovery (for REST APIs)
• Fully automated authenticated vulnerability scanning covering web apps and APIs (including OAuth single sign-on environments)
• Centralized visibility of API endpoints and vulnerabilities as part of the overall web application attack surface
• Automatic URL rewriting to enumerate and test predictable endpoints discovered during crawling
• Hundreds of mature security checks to safely and accurately detect security issues in websites, applications, and APIs

See Invicti API Security in action

API security best practices

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:

• Define an API security strategy. This should include policies and controls for API discovery, security testing, inventory, management, and protection.
• For any large production APIs, use proven security solutions to provide runtime protection. This should cover access control as well as automated traffic filtering and throttling.
• Centralize and enforce API management to help developers and security teams alike keep track of active APIs and current specification versions. This should include a standardized, automated process for API enrollment and decommissioning.
• Work with engineering teams to define secure coding standards for API design and development. These should include approved architectures, design patterns, and security controls.
• Never assume without testing that API user authentication will be handled by another system. Following such zero-trust principles becomes especially important with multi-layered APIs.
• Incorporate APIs into a consistent and continuous discovery and security testing process for web assets. This helps normalize API security as a subset of application security and integrate it into the software development lifecycle.
• Ensure your secure coding practices include input validation and sanitization. This is especially important for APIs, where protecting object identifiers is crucial to prevent IDOR vulnerabilities.
• Build API security testing into your DevOps pipelines by integrating application and API discovery and security testing with existing development tools and issue trackers.

Building a continuous web application and API security process

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.