Much of the modern Internet relies on APIs to function. API security is the process of protecting APIs from attacks and data breaches.
Después de leer este artículo podrás:
Copiar el enlace del artículo
An application programming interface (API) is a way for one piece of software to interact with another piece of software. If a program or application has an API, external clients can request services from it.
API security is the process of protecting APIs from attacks. Just as applications, networks, and servers can be subject to attack, APIs can fall victim to a number of different threats.
API security is a core component of web application security. Most modern web applications rely on APIs to function, and APIs introduce additional risk to an application by allowing outside parties to access it. One comparison is a business that opens its office to the public: having more people on the premises, some of whom may be unknown to the business's employees, introduces greater risk. Similarly, an API allows outsiders to use a program, introducing more risk to the API service's infrastructure.
API security strategies can help mitigate these and other risks.
Strong authentication and authorization measures help ensure that data is not leaked and only authorized clients make API requests. DDoS protection and rate limiting can shut down DDoS attacks. Schema validation and the use of a web application firewall (WAF) can block vulnerability exploits.
Rate limiting puts a cap on how often someone can repeat an action within a certain timeframe. If an API client exceeds the number of allowed requests, rate limiting will discard or block further requests from them for a period of time.
DDoS mitigation helps stop DoS and DDoS attacks. In a DDoS attack, an attacker tries to overwhelm an API with a lot of requests in a short amount of time. Often these requests come from multiple different sources.
Rate limiting and DDoS mitigation are crucial for APIs for a couple of reasons:
For a vulnerability exploit to work, the malicious API requests must be structured in such a way that it causes the API to respond in a way its architects did not intend. There are several ways that API developers can block such malicious requests. Two of the most important to know are:
An API's schema describes an API's expected behavior: the kind of requests it should get and the kind of responses it should provide. Invalid requests that do not conform to this schema can cause an API to behave in unexpected ways, potentially resulting in a data leak. Schema validation identifies invalid requests and responses. By blocking invalid responses, API developers can avoid some types of attacks and help prevent data leaks.
A WAF works like a traditional firewall in that it blocks some network requests and responses and allows others through. It does this based on a set of rules: if a request or a response violates a rule, or conforms to a rule, it is blocked. A WAF is deployed in front of an API or a web application, and it monitors HTTP traffic.
It is possible to set up WAF rules that block request and response patterns that target a vulnerability. WAF rules can also block requests from certain IP addresses, which helps stop bot attacks and other attackers.
Authentication ensures that API requests come from a legitimate source. Authorization lets the API server know if the requesting client or endpoint is authorized to obtain requested data.
Suppose Alice constructs an API and Bob builds a web application that uses Alice's API. When Bob's application sends an API request to Alice's API, he attaches a label that reads "this is from Bob" to the request. This authenticates Bob's request so that Alice's API server knows to treat the request as legitimate.
Alice's API server also checks what privileges Bob has. If Bob's request is for data that Alice's API has labeled "Bob can see this," the server fulfills the request. However, Alice's API may have a section of data labeled "not for Bob," and the server should not fulfill a request for that data when Bob is the requester. This is why authorization is important.
(In reality, Bob would attach a key or some other form of authentication to API requests, not just a label that says "this is from Bob.")
There are several authentication methods for APIs. The most common ones are:
The client is assigned a key — a unique string of characters that only they and the API service know. The key is attached to each API request. The API server checks for the key when it receives an API request to make sure it is from an authenticated client.
The downside of this authentication method is that if the key is stolen, an attacker can use it to impersonate a legitimate client and can then carry out a variety of attacks. It is important to encrypt requests and responses to and from an API using an encryption protocol like Transport Layer Security (TLS) — that way, the key is not exposed in plaintext as it crosses the Internet.
API requests can use typical username and password credentials for authentication via a method called HTTP authentication. In HTTP authentication, a username and password are encoded and added to the HTTP header for all API requests. The server can check these credentials against the credentials of allowed clients to authenticate the requests.
This approach comes with all the challenges normally associated with passwords: passwords can be lost, leaked, stolen, guessed, or shared with untrusted parties. Passwords are also subject to credential stuffing and brute force attacks, among others.
Instead of requiring authentication directly from the client, an API server can get an authentication token from a trusted authentication server using the OAuth protocol. To use the API, a user logs in to a third-party service instead of directly logging in to the API. Like the username-and-password approach, this authentication method is vulnerable to credential stuffing and other attacks.
TLS is the encryption protocol that creates an encrypted, authenticated connection between client and server when loading webpages. TLS can also verify and authenticate both ends of an API connection (each end is called an "API endpoint").
In mutual TLS (mTLS), both API endpoints (client and server) have a TLS certificate. They authenticate each other using these certificates, ensuring that both are who they claim to be without needing to rely on passwords or other authentication methods.
However, mTLS can be a challenge to implement: all API endpoints need legitimate TLS certificates, which may be difficult to enforce and maintain.
Cloudflare API Shield enables multiple API security features from one dashboard in order to protect against common API security risks. API Shield includes:
Read our blog post to learn more about API Shield.
Glosario de seguridad
Navegación del centro de aprendizaje