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
APIs often self-document information, such as their implementation and internal structure, which can be used as intelligence for a cyber-attack. Additional vulnerabilities, such as weak authentication, lack of encryption, business logic flaws and insecure endpoints make APIs vulnerable to the attacks outlined below.
Man In The Middle (MITM)
A man in the middle (MITM) attack 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.
API injections (XSS and SQLi)
In a code injection attack, malicious code is inserted into a vulnerable software program to stage an attack, such as cross site scripting (XSS) and SQL injection (SQLi).
For example, a perpetrator can inject a malicious script into a vulnerable API, i.e., one that fails to perform proper filter input, escape output (FIEO), to launch an XSS attack targeting end users’ browsers. Additionally, malicious commands could be inserted into an API message, such as an SQL command that deletes tables from a database.
Any web API requiring parsers or processers is vulnerable to attack. For example, a code generator that includes parsing for JSON code, and doesn’t sanitize input properly, is susceptible to the injection of executable code that runs in the development environment.
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.
API security best practices
Securing your API against the attacks outlined above should be based on:
- Authentication – Determining the identity of an end user. In a REST API, basic authentication can be implemented using the TLS protocol, but OAuth 2 and OpenID Connect are more secure alternatives.
- Authorization – Determining the resources an identified user can access. An API should be built and tested to prevent users from accessing API functions or operations outside their predefined role. For example, a read-only API client shouldn’t be allowed to access an endpoint providing admin functionality.
Additional best practices include validating your API calls against API schemas that clearly describe expected structures. Scanning payloads and performing schema validation can prevent code injections, malicious entity declarations, and parser attacks. Assigning an API token for each API call validates incoming queries and prevents attacks on endpoints.
Lastly, it’s important to secure all of your webpages using TLS/SSL, which encrypts and authenticates transmitted data, including that sent via web API. Doing so helps mitigate the threat of MITM attacks by preventing the interception of site traffic.
See how Imperva API Security can help you with web API security.
WAF and API security
A web application firewall (WAF) applies a set of rules to an HTTP/S conversations between applications. WAFs are commonly used to secure API platforms, as they are able to prevent misuse and exploitation and helps mitigate application-layer DDoS attacks.
In addition, WAFs use a list of regularly-patched, strict signatures and SSL/TLS encryption to block injection attacks and prevent the interception of site traffic in MITM attacks.
Imperva’s cloud-based WAF uses signature recognition, IP reputation and other security methodologies that identify and block code injections on APIs. SSL/TLS certificates are hosted on the Imperva CDN to prevent attacks and ensure compliance.
Using the Imperva dashboard, security teams can enforce SSL/TLS security across multiple subdomains to further secure APIs from protocol downgrade attacks and cookie hijacking attempts.
API Security is Necessary
Today, there are still API security threats that most WAFs and Advanced Bot Protection solutions cannot manage. In this post, we’ll explain these new types of threats and make some recommendations for features you need within solutions to protect your APIs.
When a bad actor makes a completely valid API call that evades detection by traditional security methods, this is a problem that’s not addressed by all Bot Protection and WAF solutions. In this attack instance, typical API Access management control cannot stop an attacker from leveraging an authorized session. This is because typical schema validation cannot detect API calls with completely conforming object payloads. In this case, the attacker, using a valid API call, tricks the application into returning user data and affects a breach.
In practical terms, here’s how it works. There is an instance where a misimplementation of a small application feature enables an attacker (as “user A”) to log in. Through some careful manipulation, “user A” can change the input parameters to reference “user B” and the attacker can perform actions and even extract data as if the request were coming from “user B”, though it is really coming from a valid “user A” login session. You can see where this would confound conventional security mechanisms. As the use of APIs increases, these attack situations become more common.
API security threats present themselves in two types; known attack patterns like injections (e.g., a log4j injection in an API input), and unknown attack patterns targeting application-specific business logics and data structure (e.g., Broken Object Authorization API calls). The latter calls for a different approach than that which traditional solutions can provide.
The benefits of a full stack of Web and API security solutions
Using the OWASP Security Top 10 as a reference to represent the expanse of threats you can face, let’s see how a stack of Web and API security solutions neutralizes them.
A10: Insufficient Logging and Monitoring
A stack of Web and API security solutions enables organizations to sufficiently log and monitor data without slowing down performance and creating a barrier to application development and deployment.
A9: Improper Asset Management
The data within APIs have as much asset value as the APIs themselves, connecting API security with data security. A stack of Web and API security solutions allows for complete visibility into both the APIs and the data woven into them and enables organizations to apply security policy holistically.
A8: Injection
A stack of Web and API security solutions provides an up-to-date Web Application Firewall (WAF) to manage code injections and zero-day vulnerabilities that can affect API security.
A7: Security Misconfiguration
Organizations tend to overlook the misconfiguration of the design of the scanning and testing of APIs. Oftentimes, API security testing and verification are as good as the schema. Unfortunately, it is often the case that schema is overlooked as a documentation practice. It is important for organizations to find ways to monitor existing APIs usage and double-verify API schema hand-generated from the code and not simply trust it as being effective. A stack of Web and API security solutions helps.
A6: Mass Assignment
In a business logic attack where, for example, a bad actor tricks an application into executing a whole update or whole command as an admin, how can a generic detection tool or mechanism create an app-specific profile that’s not dependent on the DevOps team’s input? A full stack of Web and API security solutions automates the activity to figure out how the app communicates.
A5: Broken Function Level Authorization
Developers design applications to protect critical functionality from unauthorized external users, and their principal concern is detecting unauthorized “north-south” API calls that facilitate communication between external entities and the applications. When developers compose services like “back end for front end” designs where the back end is being accessed by a trustworthy front end, the APIs use “east-west” calls to communicate internally. A full stack of Web and API security solutions can detect when your front end is relaying an unauthorized function call.
A4: Lack of Resource and Rate Limiting
Traditional API security solutions count API calls, but volume is not the most important consideration. API call type is also important, so organizations also use advanced bot protection that differentiates not only human to bot but also good bot to bad bot for additional security.
A3: Excessive Data Exposure
Monitoring API call volume is less critical than being able to detect if sensitive data is being exposed and in what context. A full stack of Web and API security solutions has the capacity to identify and classify sensitive data.
A2: Broken Authentication
Many API gateways provide strict token validation practices but random tokens can be generated as a result of account takeover (ATO). Oftentimes, bad actors just take over the account and use it to generate valid API tokens, then they can automate subsequent attacks to exfiltrate data. A full stack of Web and API security solutions goes up stream to ensure that you can protect the account properly.
A1: Broken Object Level Authorization
These are obvious attacks, but how do you automate detecting them? Focusing on data objects’ relationship to one another is critical. Remember our example of “User A” tricking the application into functioning as if “User A” were “User B”? An automated security solution can detect this anomaly where traditional approaches have failed.
API Security starts with discovery
As APIs feature an application-specific data layer, automated data discovery is necessary. This discovery process must feature the ability to identify sensitive data. The API inventory is the foundation for the detection and remediation of security incidents and it must be updated automatically to function the way it is supposed to.
Join us on May 3, 2002, for the webinar, API Security: Developing a Strategy That Keeps Pace With Your Business. Lebin Cheng, Head of API Security, Imperva and Amy DeMartine, VP, Research Director, Forrester will help you better understand how enterprises approach APIs and API security and provide meaningful insight and guidance. Specific learning objectives include:
- Gaining a global insight into the challenges that developers, security, and product teams face regarding APIs
- Get key recommendations on how to automatically secure APIs
- Find out what to look for from a vendor in an API Security solution, based on new Forrester research
This session will include robust Q&A participation, so spots are limited. Reserve your spot today.