In the modern era, REST APIs become an integral part of the applications. By adopting the REST APIs, you can expose your services to web applications or mobile applications and all other digital platforms.
REST APIs must be built as a stateless service. REST API best practices deserve a separate article. This article primarily focuses only on security best practices for REST APIs.
Below are the key concepts that should be considered while designing the REST APIs.
Before delving into details let us first understand authentication and authorization.
In the request processing pipeline, authentication comes first and authorization comes next. Authorization occurs only after successful authentication of the request.
Below are the most widely used authentication types when dealing with Remote APIs (REST APIs / Web Services).
Basic Auth is the simplest way of dealing with Authentication when compared to other methodologies.
In the Basic Auth, the user has to send the user id and password in the format of userid:password encoded in base64 format. This method is preferred only over the https protocol only. This is highly discouraged to use over HTTP as your credentials are transferring in plain format.
Plain Text
1
Authorization: Basic base64(userid:password)
Bearer Token Authentication is also known as Token-based Authentication. When the user logs into an application using the credentials, the Authorization server generates a cryptographic token to uniquely identifies the user. the applications can use the token to identify the user after a successful login. i.e. The application is required to send this token when accessing protected resources.
Similar to Basic Authentication, Bearer tokens are only recommended to send over HTTPS only.
Authorization Bearer <your token>
API Tokens are widely used in the web services/REST APIs security before the evaluation of Client-side frameworks. Still, many organizations use the API Tokens as a security measure for the APIs. This is the simplest way of implementing the security in REST APIs.
This is recommended when providing the communication between server to server requests. It is recommended to use the IP Address registration as well when using the API keys. i.e. API Token is uniquely identified along with the IP Address. This is not recommended to use as a methodology for end-user authentication and Authorization.
The API Key key can be sent as part of the query string or _Authorization token _or custom header or as part of the data.
OAuth2.0 is an authorization framework that allows users to grant a third-party website or application to access the user’s protected resources without revealing their credentials or identity. For that purpose, an OAuth 2.0 server issues access tokens that the client applications can use to access protected resources on behalf of the resource owner.
You probably see this option in the form of ‘Login using Google’, ‘Login using Facebook’, ‘Login using Github’ etc.
By default, OAuth generates the access tokens in the format of JWT (JSON web tokens). JWTs contain three parts: a header, a payload, and a signature.
OAuth2.0 provides various flows or grant types suitable for different types of API clients. Grant Types are out of scope for this article.
OIDC is a simple identity layer built on top of the OAuth2.0. OIDC defines a sign-in flow that enables a client application to authenticate a user, and to obtain information (or “claims”) about that user, such as the user name, email, and so on. User identity information is encoded in a secure JSON Web Token (JWT), called ID token.
In the Open ID Connect, Request flow will happen as below.
Input validation should be applied to both syntactical and semantic levels.
Basic Input validation guidelines
We must define the allowed content types explicitly. It is always good practice to define the valid content types and share them with the required shareholders. Upon receiving an unexpected or missing content-type header, API must respond with HTTP response status 406 Unacceptable
or 415 Unsupported Media Type
.
Content of given resources must be interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset.
JSON encoders must be used when dealing with JSON Data.
Rate limiters allow you to secure your APIs from the DDoS attacks. When exposing your API to publicly you must define the rate limiters. If you are opt-in for any cloud provider tools, they explicitly provide the rate-limiting capabilities to the public faced resources. you must adjust the configurations accordingly to your needs.
Ensure data is sent over HTTPS only. if any user tries to access over HTTP, you should upgrade it HTTPS and handle the request
Data in storage must be protected using best security practices. All the cloud providers provide you the inbuilt security (Encryption)for your backups.
Below are few common status codes used along with REST APIs
Please share your thoughts in the comments box to improve it further.
If you found this helpful please share it on Twitter, Facebook, LinkedIn, and your favorite forums. Big thanks for reading!
#rest api #microservice architecture #api security #security best practices #rest api security #architecture and design