Securing REST API
RESTful web services, are resources on the web that can be used to get specific information. These services basically portray the working of the REST API.
REST stands for REpresentational State Transfer is an architectural style not a protocol i.e. a set of guidelines for building a web service. REST can be used to modify or view resources on the server.
Each URL on the server represents a resource; either a collection resource or an element resource.
- A collection resource would be available at a URL like https://restapi.ex/users which would be a representation of a list of users.
- A element resource would be available at a URL like https://restapi.ex/users/1 which would be a representation of a single user, identified by 1.
Different HTTP methods are used for different CRUD operations:
- POST – create/new operation.
- GET – a read operation.
- PUT – a write/modify operation.
- DELETE – self-explanatory.
State (or rather, client context) is not stored on the server-side; all state is in the representations passed back and forth by the client’s requests and the server’s responses.
Securing Access Control
- Make sure that API endpoint is accessible on encrypted connection only by using HTTP/TLS.
- Build a secure authentication and authorisation mechanism, you can use standard protocols like SAML or OAuth.
- Users authentication mechanism should be centralised, stand-alone which issues access token.
- Access cookies/tokens should be expired on logouts, Revoke the access if the client violates the usage agreement.
- In order to minimise latency or other performance issues, check for authorisation at each end-point.
Protecting HTTP Methods
- Apply a whitelist of permitted http method e.g. GET POST PUT.
- Make sure the incoming method in HTTP request is valid for the session token or API key and associated resource collection, action.
- Reject all requests not matching the whitelist with HTTP response code 405 Method not allowed.
User Input Validation
- Never trust the user input parameters, json objects etc., validate on server side in respect of length, formats, type and range.
- Reject unexpected/illegal content or special characters that is not allowed.
- String input should be validated with regular expression.Log input validation failures, it will help taking further protective actions.
- Use secure parsing libraries, make sure to use latest version, for example if you are using xml parser it should not be vulnerable to XXE.
Validate Content Types
- Reject requests containing unexpected or missing content type headers with HTTP response status 406 Unacceptable or 415 Unsupported Media Type.
- Do not simply copy the Accept header to the Content-type header of the response.
- Reject the request (ideally with a 406 Not Acceptable response) if the Accept header does not specifically contain one of the allowable types.
- Ensure sending intended content type headers in your response matching your body content e.g. “application/json” and not “application/javascript”.
Protect Against Privilege Escalation
- Require API session/tokens for every request to the protected endpoint.
- The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorised use.
- You must not expose a direct reference towards a specific entity that would allow an attacker to guess/calculate references towards other entities.
Security Headers
- Disable CORS headers if cross-domain calls are not supported.
- X-Frame-Options: deny to protect against drag’n drop clickjacking attacks in older browsers.
- Send an X-Content-Type-Options: no sniff to make sure the browser does not try to detect a different Content-Type than what is actually sent.
- The server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset.
Error Handling
- Respond with generic error messages – avoid revealing details of the failure unnecessarily.
- When Exception occurs do not pass technical details in response (e.g. call stacks or other internal hints) to the client
Returning Proper HTTP Status Code
HTTP has different states code while designing REST API make sure to return correct status code in response, here is complete list of security related status codes.
Status code |
Message | Description |
| 200 | OK | Response to a successful REST API action. The HTTP method can be GET, POST, PUT, PATCH or DELETE |
| 201 | Created | The request has been fulfilled and resource created. A URI for the created resource is returned in the Location header |
| 202 | Accepted | The request has been accepted for processing, but processing is not yet complete |
| 400 | Bad Request | The request is malformed, such as message body format error |
| 401 | Unauthorized | Wrong or no authentication ID/password provided |
| 403 | Forbidden | It’s used when the authentication succeeded but authenticated user doesn’t have permission to the request resource |
| 404 | Not Found | When a non-existent resource is requested |
| 406 | Unacceptable | The client presented a content type in the Accept header which is not supported by the server API |
| 405 | Method Not Allowed | The error for an unexpected HTTP method. For example, the REST API is expecting HTTP GET, but HTTP PUT is used |
| 413 | Payload too large | Use it to signal that the request size exceeded the given limit e.g. regarding file uploads |
| 415 | Unsupported Media Type | The requested content type is not supported by the REST service |
| 429 | Too Many Requests | The error is used when there may be DOS attack detected or the request is rejected due to rate limiting |
Reference: https://www.owasp.org/
By – Girish Ametha
Engati – www.engati.com – A Coviam technologies platform
Coviam Technologies
www.coviam.com