With the rise of cloud computing, the number of APIs growth is immense. With each new API comes additional security concerns. 91% of organizations reported having an API security incident last year.
Also, Gartner estimates that “by 2022, API abuses will move from infrequent to the most frequent attack vector resulting in data breaches for enterprise web applications.
These numbers point to why it is even more important to take a firm stance in protecting APIs.
Best practices how to secure your APIs
As the industry-standard protocol for authorization, OAuth 2.0 simplifies authentication for the developers by providing standard flows for granting access.
Common OAuth 2.0 Grant Types
Grant types refer to how a client gets access to an application.
Common grant types include:
- Authorization Code - With this flow, the client first sends a request to the OAuth server to request access. The server then provides an authorization code and redirects the client back to the requesting application. The application exchanges the authorization code for a token.
- Device Flow - The device flow enables browserless clients to get an access token.
- Resource Owner Credentials - In this flow, the user’s login credentials are used to grant access to the system. In this scenario, the client is not directed to the authorization server. The client submits a request by providing the user’s login information. The token is returned directly to the application.
- Client Credentials - This is a server-to-server flow that authorizes API operations between systems with no user present. An example would be nightly operations that happen via a scheduler.
One Authorization Mechanism
No Gateway or API should ever be allowed to issue access tokens. If too many entities perform these tasks, it can become near impossible to manage the credentials used for signing keys.
Token management is a complex process that involves many processes. The OAuth server was designed specifically to handle this complexity.
Prevent Cross-site Forgery Requests
Hackers can attempt to gain access to the system by imitating an authorization request.
You can prevent this by making sure the application uses the “state” parameter.
This makes sure the response belongs to the same user that initiated the request.
Follow URI Requirements
The redirect URI must use HTTPS. It must be an absolute URL and must not contain arguments. Last, the URL must not include a “#.”
Securing APIs with Throttling
The Denial of Service (DoS) attack is such a common attack that it must be at the top of the list for protecting your APIs and all resources in a cloud environment.
Throttling limits the number of API calls a client can make within a certain time. It is important to note that throttling also helps with service reliability.
When a client calls an API, the throttling logic determines if the request is within the allowed number. If not, the API returns an error.
The client will need to wait a predetermined time before making any more calls.
There are a variety of algorithms used for throttling.
Leaky Bucket Algorithm
This algorithm uses the first-in-first-out queue to manage requests. The queue holds a specific number of requests.
As new requests come in, they are added to the end of the queue. The queue regularly processes requests from the front of the queue and new requests are added to the end of the queue.
The downside to this approach is that new requests could be discarded if the queue is already full.
Fixed Window Algorithm
Under this method, a fixed number of API calls per user are allowed within a particular period. The window is one minute.
At the beginning of the request, the counter is set to zero. Every user request during that minute increases the counter.
Once the counter reaches the time limit, any new requests are rejected.
One downside to the fixed window is a scenario known as “bursts.” A burst occurs when a large number of requests come in at the beginning of the time window.
This could overwhelm the system and slow down API performance.
Sliding Window Algorithm
The sliding window approach solves the burst issue. Here, the counter doesn’t start until the user makes the first request.
The timestamp is saved with the request which allows the system to keep track of time and the number of requests within that period.
When to use Opaque Tokens vs. JSON Web Tokens
JSON Web Tokens (JWTs) should only be used internally as they contain readable content.
Anyone with access to the token can read the information in it. However, when sending tokens to third parties, opaque tokens should be used.
Opaque tokens do not store user identity and claims directly in the token.
Instead, the token acts as a primary key to access a database entry that contains the requested information. Only the issuer knows the format.
Expire Tokens - Give tokens an expiration. Unless the signing key is changed, once a token is signed, it is valid forever.
This could cause issues if a token were to be compromised. Expiring tokens is a good way to ensure they remain valid.
Secure the JWT Payload - JWTs are plaintext and can be easily decoded. Do not store sensitive information in the payload because it could be exposed to hackers.
As companies rely more on APIs to build web applications, the need for security to minimize security risks is essential.
Following API security best practices for authorization, workload management, and token management are the backbones to minimizing a company’s risk for vulnerability.
Reach out to us to learn more about how to secure your APIs and how we can help you achieve a successful digital transformation initiative.