6. Security

The Problem

As described in the following diagram, there are several challenges to secure the access to your application (in transit and at rest) :

How do you secure the access to your application (authentication and authorization) ?

What happens if you have more requests than your application can handle ?

How do you secure the access between your application and the datastore ?

How do you protect data in your datastore ?

API Authentication

Before diving in more details on how authentication works with api, let's try to explain how the authentication works on between a traditional HTTP Client and HTTP Server. An authentication is a way to proove the web application that the user is a valid user.

(1) -> The user sends an HTTP Request (POST), including in the header the credentials (username and password)

(2) -> The server checks in its local credentials database (or with an external credentials provider, ex: LDAP), if the credentials sent are the same.

(3) -> If the credentials are valid, the server creates a session id.

(4) -> The server issues a cookie with the session id to the user.

(5) -> The user can access to the HTTP Server resources until the session expired (in that case the session id and the cookie are deleted).

Now with REST and GraphQL it's a different story, as they are stateless, there is no session created between the client and the server.

The result is for every request between a client and the API Server, the client needs to validate its identity.

We will explore the 5 authentication methods available to a client to authenticate against an API Server :

Basic Authentication

API Keys

JSON Web Tokens

HMAC

OAuth 2.0

Basic Authentication

This is probably the simplest form of authentication. The following diagram illustrated how it works :

(1) -> The user sends a POST Request usually, on the endpoint /login;

(2) -> The server replies and asks the user to send an username and password

(3) -> The user usually sends the username/password either in plain-text or encoded with Base64

(4) -> The server checks the credentials, if valid, it sends an HTTP/200 OK, in invalid HTTP/401 (Unauthorized)

Risks and Limitations

Weak security: It's important to note this method is not secured, as someone can play the man-in-the-middle and get access to the username and password.

Often, API provider accepts Basic authentication for the first request, and can issue an API Token for all other requests.

API Keys

API Key is a chain of characteres and numbers that is generated by API Providers to authorize API Consumers the access to API resources.

As illustrated in the following diagram :

(1) -> The client generates an API Key on the API Provider platform

(2) -> The client sends an HTTP Request and include the API Key either as a parameters, or it can be included in the header, the body or in the cookie

(3) -> The API Provider checks the validity of the API Key, if valid, an HTTP/200 OK is sent back to the API Consumer.

Better security than basic authentication: API Key offers more security, as the API Key can be long and complex, with an expiration date

Risks and Limitations

Weak API Key: If the generated API Key is not strong enough, it can be easily attacked by Brute Force.

Man in the middle attack: API key can be stolen if the communication between the API Consumer and the API Provider is not secured (no TLS).

Exposed : API key can be easily exposed on online repository, left in code , etc..

JSON Web Tokens

JWT (JSON Web Token) is another form of API authentication, more secure than the API Token. As illustrated in the following diagram :

(1) -> The client sends an HTTP Request with in the header the username and the password.

(2) -> The API Provider checks the validity of the user.

(3) -> If the credentials are valid, the API Provider sends back a JWT to the user.

(4) -> The user adds the JWT in the Authorization header in all the API requests.

How the JWT is generated on the server-side

As illustrated in the following diagram, a JSON Web Token is generated with the following details :

(1) -> The header includes the information about the algorithm for signing the payload.

(2) -> The payload includes the data inside the token (username, timestamp, the issuer)

(3) -> The signature validates the token.

(4) -> The Token (JWT) is the result the hash signature (encoding the header, the playload + secretpassword)

Risks and Limitations

Less secure if encryption not used: Some API Provider might implement JWT without proper encryption, which might result to only a base64 encoding version, which can be easily decoded, the JWT can in this case be easily stolen or brute-forced.

HMAC

HMAC stands for "Hashed-based message authentication", and is another form of api authentication, it's mainly used by AWS. As illustrated in the diagram below :

(1) -> The Provider shares a secret with the consumer (API client)

(2) -> For every interaction with the API, the user calculates the hash of the requested data and the secret, resulting to a message digest.

(3) -> The message digest is added to the request when making an API call to the Provider

(4) -> The Provider calculates the hashed message and compares the result with the message digest (in the client's request). If it matches the client's request is considered as authentic and a response is sent back with the requested data.

Risks and Limitations

Encryption algorithm: HMAC supports the (HMAC-MD5, HMAC-SHA1, HMAC-SHA256, HMAC-SHA512); There is no known vulnerability on the HMAC-MD5 and HMAC-SHA1, but there are definitely less secure than the HMAC-SHA256 and HMAC-SHA512. Some trade-offs should be considered (performance/security), longer hash value might impact the performance.

Compromised secret: The shared secret needs to be kept in a secure place.

OAuth 2.0

OAuth is a standard created mainly to simplify the services to services communication easier.

One example is for instance if you need to allow your tiwtter account to post your tweets on Linkedin. As Linkedin and Twitter have implemented OAuth, you can easily authorize linkedin to access your twitter account.

The following diagram illustrates the OAuth authentication process:

(1) -> The application client (Linkedin), sends an authorization request to the user or resource owner (Twitter)

(2) -> The resource owner grants the authorization to the application client

(3) -> The application client (Linkedin) sends its authorization to the authorization server (Twitter authorization server)

(4) -> Once the authorization grant validated, the authorization server sends a token to the application client

(5) and (6) -> The application client (Linkedin) uses the token for all the api requests to the Resource server (Twitter API Server)

---

According to a Akamai study report 84% of respondents experienced an API security incident over the past 12 months and according to this report 95% of attacks originate from authenticated users.

---

OWASP Top 10 API Security Risks

OWASP stands for Open Worldwide Application Security Project, the goal is to raise awareness among professionnals on the top security vulnerabilities and improve their security posture.

They publish Top 10 vulnerabilities list impacting the trending application ecosystem and framework, like :

OWASP Cloud-Native Application Security Top 10

OWASP Machine Learning Security Top 10

OWASP Top 10 CI/CD Security Risks

OWASP Top 10

OWASP Top 10 API Security Risks

We're going to focus on the OWASP Top 10 API Security risks.

#1. Broken Object Level Authorization: This vulnerability allows attacker to bypass access control mechanisms, and manipulate the object properties without proper permissions.

#2. Broken Authentication: This vulnerability allows attacker to compromise authentication tokens. This happens when authencation mechanisms are implemented incorrectly.

#3. Broken Object Property Level Authorization: If there is no proper object level authorization, attacker can gain access to more information (than they are supposed to have)

#4. Unrestricted Resource Consumption: In this scenario, attackers might send unlimited requests (denial of services) causing an increase in operational costs.

#5. Broken Function Level Authorization: In this scenario, if you implement complexe level authorization on your resources, with no proper adminstrative rules; it can lead to improper access authorization to resources.

#6. Unrestricted Access to Sensitive Business Flows: API might expose business logic (like creating a user, ordering a product,..) which may impact the business itself, if some use cases have been fully tested under heavy load (excessive multiple requests).

#7. Server Side Request Forgery: In this scenario, attacker (with a valid authentication) can manipulate the server to make unintended requests to internal or external resources;

#8. Security Misconfiguration: In this scenario, if an API is developped to be more customizable, and that developers do not follow security best practices, it might increse the surface attack.

#9. Improper inventory management: API usually offer multiple endpoints; if there is no clear inventory management, some old version of apis, might be exposed unnecessarily.

#10. Unsafe Consumption of APIs: In this scenarion attackers might use third party api, to compromise your apis.