API Security

What Is an API

An Application Programming Interface (API) is a software intermediary that allows your applications to communicate with one another. It provides routines, protocols, and tools for developers building software applications, while enabling the extraction and sharing of data in an accessible manner.

Web APIs connect between applications and other services or platforms, such as social networks, games, databases and devices.

Additionally, Internet of Things (IoT) applications and devices use APIs to gather data, or even control other devices. For example, a power company may use an API to adjust the temperature on a thermostat to save power.

SOAP API and REST API

SOAP and REST are two popular approaches for implementing APIs.

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol for exchanging information among computers. SOAP’s built-in WS-Security standard uses XML Encryption, XML Signature, and SAML tokens to deal with transactional messaging security considerations. SOAP also supports OASIS and W3C recommendations.

SOAP’s built-in standards and envelope-style of payload transport require more overhead compared to working with other API implementations, such as REST. However, organizations that require more comprehensive security and compliance may benefit from using SOAP.

REST (Representational State Transfer) uses HTTP to obtain data and perform operations on remote computer systems. It supports SSL authentication and HTTPS to achieve secure communication.

REST uses the JSON standard for consuming API payloads, which simplifies data transfer over browsers. REST is stateless – each HTTP request contains all necessary information, meaning that neither the client nor the server are required to retain any data to satisfy the request. Unlike SOAP, which requires parsing and routing for each request to function on a local web service, REST leverages standard HTTP requests and does not require the repackaging of data.

API Security Threats: OWASP API Top 10 and More

Cybercriminals are increasingly exploiting vulnerable APIs to breach systems and exfiltrate data. Notably, business logic attacks are the most common type of API-related security threat, allowing an attacker to manipulate the API’s functions, data, or workflows for malicious intent. Below are the most common API security threats, as identified in the Open Web Application Security Project (OWASP) Top 10 API Threats list.  

Broken Object-Level Authorization

This refers to a vulnerability in an API’s authorization system that allows an unauthorized user to access resources that they should not have access to. APIs tend to expose endpoints that handle object identifiers, creating an expansive attack surface. The vulnerabilities can occur when the API does not properly check the permissions of the user before allowing them to access a resource.

For example, consider an API that manages a list of users and their permissions. If the API does not properly check the permissions of the user before allowing them to access a specific user’s information, an unauthorized user could potentially access that information.

To address this issue, companies can take the following steps:

• Implement proper object-level authorization checks: The API should check the permissions of the user before allowing them to access any resources. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
• Use a robust and secure authorization system: The API should use a secure and well-tested authorization system, such as OAuth or JWT, to ensure that user permissions are properly checked.

Broken User Authentication

Authentication vulnerabilities allow unauthorized users to gain access to the API. This can occur when the API does not properly verify the identity of users before granting them access, or when it uses weak or easily compromised authentication methods. A typical anatomy of a broken authentication attack is a man in the middle (MITM) attack that involves an attacker secretly relaying, intercepting or altering communications, including API messages, between two parties to obtain sensitive information. For example, a perpetrator can act as a man in the middle between an API issuing a session token in an HTTP header and a user’s browser. Intercepting that session token would grant access to the user’s account, which might include personal details, such as credit card information and login credentials.

To address broken user authentication:

• Use strong and secure authentication methods: The API should use strong and secure authentication methods, such as hashed and salted passwords or two-factor authentication.
• Implement proper password policies: The API should enforce strong password policies, such as requiring the use of long and complex passwords, to reduce the risk of password-related vulnerabilities.
• Monitor failed login attempts: The API should have logging in place to monitor failed login attempts, allowing companies to identify and respond to potential security threats.

Excessive Data Exposure

Developers often expose more data than is necessary through an API. This can occur when an API does not properly control access to data, or when it returns more data than is necessary in response to a request. Exploitation of Excessive Data Exposure is simple, and is usually performed by sniffing the traffic to analyze the API responses, looking for sensitive data exposure that should not be returned to the user.

Excessive data exposure can create security risks because it reveals sensitive or confidential data to unauthorized users. It can also create performance issues, as returning unnecessary data can increase the size of API responses and slow down the API.

To address excessive data exposure:

• Review and limit the data that is exposed through the API: The API should only expose the minimum amount of data that is necessary to fulfill the requests of its clients. Understand the nature of data that is exposed to the outside world and association of those sensitive data types to inbound API calls. This allows for detection of sensitive data when it is exposed, and in what context. A full stack Web Application & API Protection (WAAP) solution has the capacity to identify and classify sensitive data.
• Use selective data exposure: The API should only expose the specific data that is requested by its clients, rather than returning all data associated with a particular resource.
• Maintain an API inventory: Perform continuous inventory of internal and external APIs. In addition, conduct a regular discovery of sensitive data via APIs in the inventory.
• Categorize data: Add customized data labels to indicate API attributes which are critical or sensitive for your organization.

Lack of Resource and Rate Limiting

This refers to a lack of controls on the number of requests that can be made to an API within a given time period. An attacker can make a large number of requests to the API, potentially causing a denial of service (DoS) attack or other types of abuse.

To ensure sufficient resource and rate limiting: 

• Check existing resource and rate limiting controls: The API should have controls in place to limit the number of requests that can be made to it within a given time period. Assess the limits to determine if they are appropriate.
• Set appropriate limits: Set call and volume limits that match expected usage patterns. For example, if the API is intended for use by a small number of users, the limits could be set relatively low. If the API is intended for use by a large number of users, the limits would need to be set higher. Further, consider using advanced bot protection to differentiate automated and human traffic, and to understand what proportion of traffic is coming from good and bad bots.

Broken Function-Level Authorization

This allows an unauthorized user to perform actions that they should not have access to. Broken function-level authorization can occur when the API does not properly check the permissions of the user before allowing them to perform a particular action.

For example, consider an API that allows users to create and delete accounts. If the API does not properly check the permissions of the user before allowing them to delete an account, an unauthorized user could potentially delete any account they choose.

To address this issue:

• Implement an authorization policy: Ensure the organization has a clearly defined policy outlining who can perform each function.
• Regularly review and test the authorization system: Ensure that it is functioning properly and that all relevant permissions are being checked.

Mass Assignment

Mass assignment allows an attacker to modify multiple parameters in an API request, potentially allowing them to gain unauthorized access or perform unintended actions. This can occur when an API does not properly validate or filter input data, and allows an attacker to modify parameters in the request body or query string.

To address mass assignment vulnerabilities:

• Implement input validation and filtering: Ensure that the API is properly formatted and meets certain requirements before it is processed.
• Use strong data types: The API should use strong data types, such as integers or booleans, for parameters that are not intended to be modified by users.
• Use whitelists: These should specify which parameters are allowed in requests, rather than using blacklists to specify which parameters are not allowed.

Security Misconfiguration

Security misconfiguration issues typically involve insecure configurations and defaults that expose sensitive data or fail to secure access:

• Conduct regular security audits: These help identify misconfiguration issues and missing patches and updates.
• Use secure configurations: The API should avoid using default configurations, such as leaving debugging mode enabled. 
• Assess: Use scanners and manual reviews to test the entire stack and identify security misconfigurations. 
• Prevent data exposure: Avoid including sensitive information in error messages. 

Injection Flaws

These vulnerabilities allow an attacker to send malicious data to the API, which is then executed as a command by the API or the underlying system. Examples include SQL injection, in which an attacker injects malicious SQL code into an API, and command injection, in which an attacker injects malicious shell commands into an API.

To address injection flaws:

• Validate and filter input data: Ensure all data is properly formatted and meets certain requirements before it is processed.
• Use parameterized queries: When interacting with a database, the API should use parameterized queries, rather than building queries dynamically. 
• Escape special characters in input data: This can prevent them from being interpreted as part of a command.

Improper Asset Management

Improper asset management refers to the failure to properly manage and maintain the assets of an organization, including exposed endpoints. 

To improve asset management:

• Maintain an asset inventory: Keep an up-to-date inventory of the resources and functionality exposed through the API.
• Implement endpoint management: Properly manage the endpoints of the API, including keeping them up to date and properly secured. 

Inadequate Logging and Monitoring

A lack of proper monitoring and logging of API activity can make it difficult to detect and respond to security incidents. Thus, an attacker can perform malicious actions without being detected.

To avoid this risk: 

• Ensure proper logging is in place: Logs should record important events, such as failed login attempts, unauthorized access to resources, and other security-related activities.
• Monitor log data: Use regular processes to review and analyze log data to identify potential security incidents.
• Set up alerts: Configure alerts to notify the appropriate personnel when potential security incidents are detected.
• Conduct regular security audits: Identify security issues that may have been missed by the logging and monitoring systems.

Additional Threats

The following threats are not included in the OWASP Top 10, but are still a significant risk to be aware of.

Distributed denial of service (DDoS)

In a distributed denial-of-service (DDoS) attack, multiple systems flood the bandwidth or resources of a targeted system, usually one or more web servers. A DDoS attack on a web API attempts to overwhelm its memory and capacity by flooding it with concurrent connections, or by sending/requesting large amounts of information in each request.

For example, a DDoS attack on the FCC website in early 2017 used commercial cloud services to issue a massive amount of API requests to a commenting system. This consumed available machine resources and crowded out human commenters, eventually causing the website to crash.

Bad Bots

APIs are a ripe target for botnet operators because they offer a direct path to the sensitive data which can be scraped, shared, or sold on the Dark Web.

Automated attacks targeting APIs can be difficult to prevent because bots are designed to mimic legitimate human behavior in order to evade detection. Unlike other types of attacks, botnets operate 24/7 and are purposefully designed to carry on repetitive tasks that are harder for humans to maintain. 

Organizations struggle to ensure the security of their APIs because they rely on simple authentication tokens or basic IP rate-limiting. Unlike the authentication of human users through multi-factor authentication, API tokens are often a single factor authenticating an API call. As attacks become more complex, combining bot detection and API security can differentiate a bot from a human user and bot, and mitigate the potential for automated fraud.

API Security Best Practices 

Implement Access Control

Access control systems are essential to ensure that only users or systems that have been granted permission can access protected resources. Effective controls are especially important when providing access to third parties.

In addition to strong authentication methods, such as OAuth or multi-factor authentication, organizations should use firewalls or API gateways to protect their APIs. A firewall can be used to block unauthorized access to an API by examining incoming traffic and only allowing traffic that meets certain criteria to pass through. An API gateway is a server that sits between the API and its clients, acting as a reverse proxy. It can be used to implement authentication, authorization, rate limiting, and other security measures.

Implement Data Classification 

By classifying data according to its sensitivity, organizations can implement appropriate security controls to ensure that only authorized individuals have access to sensitive data.

For example, if an organization has an API that allows access to customer data, it may classify this data as sensitive and implement security measures to ensure that only authorized individuals can access the data. This can help to prevent unauthorized access to sensitive data and protect the privacy of customers.

Validate Parameters

Parameter validation is the process of verifying that input parameters (also called arguments) passed to a function or method are of the correct type and meet certain criteria. Parameter validation is used to ensure that an application or system processes only valid and expected input, and to prevent the processing of malicious or malformed input.

Encrypt API Requests and Responses

Encryption helps to protect the confidentiality and integrity of the data being transmitted. Without encryption, an attacker who is able to intercept the communication between an API and its clients could potentially view or modify the data being transmitted (i.e., man-in-the-middle attacks). A common way to encrypt API traffic is to require the use of HTTPS and SSL/TLS.

Continuous Security 

Continuous security involves continuously monitoring and improving the security of an API over its lifecycle. This approach helps to ensure that an API is secure and compliant with relevant regulations and standards, and can help organizations to quickly identify and address potential security vulnerabilities or risks.

There are a number of different ways that organizations can implement continuous security for their APIs, including:

• Continuous testing: Regularly testing the security of an API can help to identify potential vulnerabilities and ensure that any identified issues are promptly addressed. This can include testing for vulnerabilities such as injection attacks, cross-site scripting, and authentication weaknesses.
• Continuous monitoring: Monitoring the security of an API on an ongoing basis can help to identify potential security threats in real-time and take appropriate action to prevent or mitigate those threats. This can include monitoring for suspicious activity, such as unusual access patterns or attempts to access restricted data.
• Continuous training: Ensuring that developers and other stakeholders are trained on the latest best practices for API security can help to prevent mistakes and ensure that the API is secure. This can include training on topics such as secure coding practices, authentication and authorization, and data protection.

Imperva API Security Makes It Easier to Monitor and Discover APIs While Mitigating Data Leakage and API Abuses

Imperva API Security provides continuous protection of all APIs using deep discovery and classification of sensitive data to detect all public, private, and shadow APIs to empower security teams to implement a positive security model. 

The product works across legacy, hybrid, and cloud-native environments—including Kubernetes, AWS Lambda, legacy monolithic apps, standalone microservices, web proxies, or API gateways that integrate with other existing infrastructure.

Imperva API Security is a product uniquely designed to benefit both the security and development teams. As a core component of the Imperva Web Application & API Protection (WAAP) platform, organizations get a unified solution to protect legacy and cloud-native applications from online fraud, DDoS attacks, and API abuses.