API security is the practice of protecting the application programming interface (API) from attacks that would maliciously use or attempt to exploit an API to steal sensitive data or disrupt services. API security employs strategies, techniques and solutions to ensure that only authorized users can access and use an API and that the data transmitted through the API is protected from unauthorized access or manipulation.
Because APIs work as the backend framework for systems and services, it’s critical to secure APIs to protect the sensitive data they transfer — including access information, such as authentication, authorization, input validation and encryption. API security refers to the methods and tools designed to protect these backend frameworks and mitigate attacks from access violations, bot attacks and abuse.
Common Types of API Attacks
A successful API attack can result in mass data losses, stolen private or personal information, and service disruption.
API stands for application programming interface, which consists of a set of definitions and protocols that allows software components to communicate. Serving as an intermediary between software systems, the API enables software applications or services to share data and functionality. But the API does more than provide connectivity infrastructure. It also governs how software applications are permitted to communicate and interact. The API controls the types of requests exchanged between programs, how requests are made, and which data formats are permissible.
APIs allow organizations to share data with customers and other external users. Types of APIs include those used for payment processing, video conferencing, social media, texting, medical or fitness monitoring, and smart homes. APIs can be open or closed, public or private, and typically conform to architectural standards, such as REST, SOAP or GraphQL.
APIs also benefit developers by giving them access to the functionality of other applications, alleviating the need to repeatedly build a new connectivity infrastructure or even understand its underlying code or architecture.
Figure 1: Modern application structure
Apps are ubiquitous, an integral part of business and society. And behind nearly every app is an API, elevating API security to mission critical.
APIs serve as the backend framework for most cloud-native applications, including mobile apps, web applications and SaaS as well as internal, partner-facing and customer-facing applications. To put API use in perspective, Postman, the API management platform, saw 1.13 billion API calls in 2022. With the rise of the API, of course, comes a potentially lucrative attack surface luring bad actors.
Because APIs expose application logic, resources and sensitive data — including personal identifiable information (PII) — they have become a target for attackers. If attackers are able to access unprotected APIs, they can disrupt business, access or destroy sensitive data, and steal property.
Figure 2: Modern microservices application leveraging APIs
Web application security in the monolith application era consisted of deploying a web application firewall (WAF) at the perimeter to intercept and inspect HTTP traffic sent by web clients. WAFs provided, and continue to provide, effective application security when the potential risk to the application primarily involves malicious user input embedded in standard HTTP web form submissions or browser requests.
But the nature of web applications has changed from monolithic applications hosted by individual web servers to containerized, cloud-native applications distributed across a cluster of host servers.
Today’s developers and security teams — dealing with highly distributed, cloud-native microservices architecture — must contend with perimeter-less networks. Modern apps consume input from a broad range of sources — standard web requests, mobile device API calls, cloud events, IoT device telemetry communication, cloud storage, etc.
Client inbound HTTP requests (i.e., north-south traffic) are often the first in a sequence of communication flows. In many cases, a single inbound request generates dozens of internal API calls (i.e., east-west traffic). If those internal API calls aren’t properly inspected and validated, API endpoints are left unprotected.
Inspecting input at the perimeter isn’t enough to catch hazardous payloads. Internal API endpoints can be misconfigured and allow unauthorized access to individual microservices, exposing application logic to malicious actions. It’s critical that all API endpoints, external and internal, are continuously monitored and secured.
Video: Overview of API security and tips for enhancing API security
As organizations rely on APIs to drive business, attackers are on the prowl for API flaws to exploit. This example of an API attack targeting an e-commerce application with a mobile application as frontend illustrates how easy it is for threat actors to find inroads to valuable data.
Figure 3: The anatomy of an API-based attack
Step 1: By reverse engineering the mobile app, an attacker discovers a deprecated API endpoint URL used for retrieving data from a backend microservice.
Step 2: The attacker notices that neither authentication nor authorization are required for sending API calls to this endpoint.
Step 3: The attacker abuses the SQLi vulnerability. The API endpoint URL provides a unique product identifier in the form of a numeric value, and the attacker runs a series of automated checks to discover that the input field <product_id> can be leveraged to carry out a successful SQLi attack.
Step 4: Rather than abusing this SQLi for data tampering, the attacker chooses to abuse the SQLi vulnerability and runs a shell command in the microservice running the SQL database. The shell command downloads a malicious executable and executes it. The executable is a bitcoin mining software.
API misconfigurations, logic flaws and vulnerabilities leave applications and data exposed to attackers. Although an API gateway can only see API traffic routed through the gateway and doesn't offer visibility to internal traffic, some organizations relegate their API security to an API gateway, believing it provides full API protection.
Security teams need visibility across their API surface. You can’t protect what you can’t see — and what you can’t see ultimately becomes the undetected activity of bad actors who discover a shadow API.
While API gateways effectively monitor APIs and API usage, they’re unable to detect and block attacks. API security requires real-time protection against malicious attacks — in addition to visibility and risk management.
The Open Web Application Security Project (OWASP) published a list in 2019 of the top 10 API security risks to bring awareness to API security risks affecting modern web applications. This list outlines the most common attacks against web APIs and includes tips for protecting your APIs from these threats.
Broken Object Level Authorization
Endpoints that handle object identifiers are frequently exposed by APIs, resulting in a level access control issue that broadens the attack surface. If proper authorization checks aren’t implemented, for example, attackers could substitute the ID of a resource that belongs to another user during an API call. Known as an insecure direct object reference (IDOR) attack, this allows the attacker to access a resource they weren’t authorized to access.
Broken User Authentication
API authentication mechanisms make easy targets because they’re exposed to everyone. A poorly implemented authentication mechanism, referred to as a broken API authentication vulnerability, gives ingress to attackers who can exploit implementation flaws to assume the identity of authorized users.
API authentication misconfigurations can occur when industry best practices are bypassed, as in failing to implement access token validation or storing credentials and keys in API endpoint URLs.
Excessive Data Exposure
The more data exposed, the greater the risk. During API implementation, developers sometimes expose object properties without itemized restrictions and rely on the client to filter out unnecessary data before it’s displayed in the UI. But even if the API client filters out the sensitive data, attackers can still exploit the initial API call and perhaps gain access to credit card numbers, login credentials and Social Security numbers.
Lack of Resources and Rate Limiting
APIs that don’t restrict the number of resources a client can call are vulnerable to API abuse via traffic overload. This type of overload degrades the API server's performance, locking out legitimate users and perhaps resulting in a DoS. API server overload also exposes the API to authentication flaws, such as brute force.
Broken Function Level Authorization
One of the challenges that API developers face is the complexity of implementing access control policies for different hierarchies of user groups and roles. The hazy distinction between administration and regular functions creates authorization flaws that attackers can exploit to gain access to a user's resources or perform unauthorized administrative functions.
Mass Assignment
A mass assignment vulnerability arises when client-supplied data is bound to data models without being filtered against a whitelist that would prevent users from assigning data to protected fields. With this vulnerability, attackers can gain access to sensitive data by intercepting API queries and changing the properties of stored backend objects by guessing object properties, reading documentation and scouring API endpoints for hints on how to compromise the data attributes of a private API.
Security Misconfiguration
Security misconfigurations can expose sensitive user information and system details, potentially resulting in a compromised server. Common causes include permissive cross-origin resource sharing (CORS), incomplete or ad hoc configurations, incorrect HTTP headers or HTTP methods, insecure default configurations, incomplete or incorrect configurations, and verbose error messages exposing sensitive information.
Injection
APIs are subject to injection vulnerabilities — SQL injection, NoSQL injection and command injection — that can occur when untrusted data is sent to an interpreter as part of a command or query. An attacker can trick an interpreter into executing dangerous commands, exposing unauthorized data for manipulation and theft.
Improper Assets Management
APIs expose more endpoints than traditional web applications, and strong API management that tracks these endpoints is essential to prevent API abuse of exposed sensitive or vulnerable API endpoints. Deprecated API endpoints or debug endpoints, for example, could be used by attackers to compromise the application.
Insufficient Logging and Monitoring
Inadequate logging and monitoring, though not a direct threat, delays detection of malicious activity. Bad actors work under the cloak of darkness with ample time to advance attacks and progress to different systems to alter, extract and destroy data. Detection of the persistent threat can take longer than 200 days, according to breach studies. And in the aftermath of a data breach, without proper logging and monitoring, organizations lack the forensics information to assess the damage.
Video: Learn about OWASP, AppSec and the OWASP Top 10 application security risks
SOAP, REST and GraphQL are three common API architecture patterns, and each API architectural style presents distinct security considerations.
SOAP (simple object access protocol) is a protocol for exchanging structured data in the implementation of web services in computer networks. SOAP uses XML as its message format and can be carried over a variety of lower-level protocols, including HTTP and SMTP. SOAP APIs are typically secured using a combination of transport layer security (such as HTTPS) and message-level security (such as XML digital signatures and encryption).
SOAP API security involves protocol extensions for dealing with security issues. SOAP adheres to the Web Services (WS) specifications, which ensure enterprise-level security for all web services through features such as WS-ReliableMessaging, which extends built-in error handling support.
The architecture of representational state transfer APIs, or REST APIs, relies on JSON data transfer and HTTP/S transfer protocol, both of which simplify REST API development compared to other API architectures. RESTful APIs use HTTP requests to POST (create), PUT (update), GET (read), and DELETE (delete) data.
Lacking built-in security provisions, REST API security hinges on the API design. Data transmission, deployment and client interaction services must incorporate security considerations. Most RESTful APIs will rely on transport layer security (such as HTTPS) and token-based authentication.
A common architectural choice for addressing REST API security is to deploy REST APIs behind an API gateway, and then provide this connectivity option to clients. An API gateway, though, isn’t equipped to defend against the gamut of security threats.
SOAP and RESTful APIs support HTTP requests and responses, as well as the secure sockets layer (SSL), but commonality ends there. SOAP APIs, with built-in security features, are inherently secure. RESTful APIs, by contrast, must be made secure through implementation and architectural choices.
GraphQL is an open-source API language that both describes how clients request information and acts as a runtime to fulfill queries with existing data. GraphQL syntax is used by developers to make specific data requests from single or multiple sources. With GraphQL, clients can define the data structure for a request, and the server will ensure that the exact structure is returned.
Enforcing GraphQL API security poses challenges related to customizable and flexible requests. The server may not be able to handle complex queries and could inadvertently execute malicious queries in the process.
Methods for mitigating GraphQL API security risks include throttling and setting a maximum query depth, as well as a query timeout to defend against large queries.
With APIs increasingly made publicly available, it’s important to address risks of data exposure by implementing best practices to minimize attack surface, remediate vulnerabilities and apprehend malicious activity in near-real time.
Ensure that only authorized users can access the API with secure authentication methods, such as OAuth2 or JSON web tokens (JWTs).
Implement rate limiting on your APIs to prevent brute-force attacks and other malicious behaviors. Rate limiting restricts the number of requests that can be made to an API within a specified period.
API requests and responses should be made using HTTPS to ensure they’re encrypted and secure. This is particularly critical when dealing with sensitive data.
Regularly assess the security of your APIs to identify potential vulnerabilities. Review changes to API inventory to detect newly exposed APIs and their risk profiles, including exposure to sensitive data, exposure to the internet, workload vulnerabilities and authentication level.
An API key is a unique identifier used to identify the application calling an API and verify authorization of access. API keys differ from authentication tokens in that they identify the application (or website) making the API call, rather than the person using the application (or website). Both are important security measures.
Follow API key storage best practices to avoid unwanted calls, unauthorized access and potential data breach with loss of personal information.
Manage and monitor API specifications, documentation, test cases, traffic and metrics. Block unwanted activity, such as malicious API traffic and bad bots, to help protect the application and reduce unnecessary costs.
Embed security early in the CI/CD pipeline and provide training to improve your developers’ knowledge of security risks, such as weak authentication and logical vulnerabilities. Implement DevSecOps principles, including collaboration between security and development teams.
Identify weak points in your API lifecycle by routinely looking for OWASP API Security Top 10 risks. Use API scanning tools and techniques to identify each API vulnerability and resolve immediately to prevent exploitation.
Requiring a security token for authentication is a first line of defense. Security tokens protect APIs from unauthorized access by rejecting the API call if a user’s token fails verification.
Best practices, in short, should start with visibility and monitoring of your attack surfaces, which can auto-discover all the web applications and API endpoints within your environment. Defense layers should include policies for north-south and east-west traffic to block malicious threats, whether they originate from the internet or within your applications.
Adding another layer of vulnerability and compliance scanning, along with strong authentication, will further protect your applications. You’ll also need to secure your workloads or the infrastructure layer, such as the hosts, VMs, containers and serverless functions that help host your applications.
Prisma Cloud provides complete API discovery, risk profiling and real-time protection for all APIs as a part of its comprehensive cloud-native application protection platform (CNAPP).
What is a monolithic application?
A monolithic app is built as a single unit, independent from other computing applications, with most or all of its functionality in one process or container. Software programs were traditionally designed as monolithic applications and included all required components layered within the software application — APIs, services, data access, databases, etc. Designed as such, monolithic apps perform all functions needed to complete a task, from acquiring user input to processing and storing data in a database.
What is service-oriented architecture?
Service-oriented architecture refers to a software design where services or data exchanges are provided by application components to other components via a communication protocol transmitted over a network.
What is microservice architecture?
Microservice architecture involves building applications by dividing their functionality into modular components. Applications are constructed of loosely coupled microservices that communicate through lightweight protocols.
Loosely coupled microservices enable developers to create complex applications with speed and relative ease. This type of cloud-native architecture can also keep pace with evolving customer needs, as the decoupling nature of microservices allows developers to push new code and functionality more frequently than they would otherwise be able.
What is simple object access protocol (SOAP)?
SOAP is a method of exchanging information between applications using a lightweight XML-based protocol. While usually transmitted over an HTTP session, SOAP messages can be sent however an application requires, as long as the client and server use the same method.
What is transport layer security?
Transport Layer Security (TLS) is an encryption protocol that protects computer network and internet communications. Common examples of TLS in use include HTTPS, email and texting. TLS replaced SSL (secure sockets layer).
What is an API endpoint?
An API endpoint is the single accessible resource in an API. When an API interacts with another system, API endpoints are the touchpoints of communication. These touchpoints, or endpoints, are the location from which the API accesses resources needed to carry out its function. Because API endpoints make systems vulnerable to attack, preventing misuse through API monitoring is vital.
What is API security testing?
Best integrated into the DevOps pipeline, API security testing is a practice that challenges the security of an API’s endpoints to verify compliance with security best practices. To evaluate authentication, encryption, conditions of user access, for example, the API is subjected to deliberate input challenges designed to emulate the attack vectors of bad actors to flush out undefined behaviors, bugs and other vulnerabilities. Findings of API testing could include authorization or authentication bypasses, security misconfigurations, SQL and OS command injections, and open-source code vulnerabilities.
API security testing can involve dynamic or static security testing as well as software composition analysis (SCA). SCA checks code in an application against CVE databases. When issues are identified, the SCA tool alerts developers that the application or API is using a library or framework with a known vulnerability. Given the widespread use of open source in API development, software composition analysis plays a critical part in API and application security testing.
What is an API gateway?
An API gateway is a tool that sits between an application and a set of backend services, acting as a reverse proxy to accept API calls. The API gateway breaks each call into multiple requests and routes these to the appropriate services, each of which produces a response while the API gateway tracks all activity.
What is a shadow API?
A shadow API, also called a zombie API, is a clandestine, nondocumented and nontracked API. Developers are often unaware of their presence and qualities.
What is OpenAPI?
An open API, also called public API, is a publicly available application programming interface that provides developers with access to a software application or web service.
What is a private API?
A private API is an application programming interface that has its application hosted by an organization to serve as a frontend interface to backend data and application functions. The interface provides a point of entry for authorized employees and contractors working to develop those functions.
What is DLL injection?
DLL injection is a type of attack that exploits processes and services of the Windows operating system. By replacing a required DLL file with an infected version and planting it within the search parameters of an application, the infected file will be called on when the application loads, activating its malicious operations.
What is a webhook?
A webhook is an HTTP-based callback function that enables event-driven interaction between two APIs, allowing web applications to receive small amounts of data from other apps. But webhooks are not APIs. They’re often called reverse or push APIs because webhooks trigger the server to send the client an HTTP POST request once data is available (instead of receiving and responding to an HTTP request). Applications must have an API to use a webhook.
In GitOps environments, webhooks can trigger automation workflows and reduce the number of steps needed to implement Git-heavy deployment pipelines, including automatically launching infrastructure-as-code workflows.
