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.
An 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 the API endpoint is accessible on encrypted connection only by using HTTP/TLS.
To build a secure authentication and authorization mechanism, you can use standard protocols like SAML or OAuth.
Users' authentication mechanism should be centralized, stand-alone which issues access tokens.
Access cookies/tokens should be expired on logouts, Revoke the access if the client violates the user agreement.
In order to minimize latency or other performance issues, check for authorization at each end-point.
Protecting HTTP Methods
Apply a whitelist of permitted HTTP methods e.g. GET POST PUT.
Make sure the incoming method in the 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 the 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, will help to take further protective actions.
Use secure parsing libraries, make sure to use the 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 unauthorized 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 an 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 the complete list of security-related status codes.
Kommentit