An API key is a valuable strategy to provide a level of identity to consumers of a RESTful API. In addition to providing tiered services, another benefit of using API keys is the ability to throttle usage of the API, and the logging of all API calls made allows API providers to limit the rate of consumption for all API users. Putting caps on the number of API calls that can be made for any single API resource, dictating consumption by the second, minute, day, other relevant constraint.
Protect HTTP Methods
RESTful APIs often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record).
Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record.
Whitelist Allowable Methods
It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity.
For example, a GET request might read the entity, while PUT would update an existing entity, POST would create a new entity, and DELETE would delete an existing entity.
It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a 403 Forbidden).
Protect Privileged Actions and Sensitive Resource Collections
Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:
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.
Protect Against Cross-Site Request Forgery
For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross-Site Request Forgery. Typically, one would use a token-based approach.
CSRF is easily achieved — even using random tokens — if any XSS exists within your application, so please make sure you understand how to prevent XSS.
Everything you know about input validation applies to RESTful web services, but add 10%, because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:
Assist the user > Reject input > Sanitize (filtering) > No input validation
Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and chair" (PEBKAC).
Web applications/web services use input from HTTP requests (and occasionally files) to determine how to respond.
Attackers can tamper with any part of an HTTP request, including the URL, query string, headers, cookies, form fields, and hidden fields, to try to bypass the site’s security mechanisms.
Common names for common input tampering attacks include: forced browsing, command insertion, cross site scripting, buffer overflows, format string attacks, SQL injection, cookie poisoning, and hidden field manipulation.
XML Input Validation
XML-based services must ensure that they are protected against common XML-based attacks by using secure XML-parsing.
This typically means protecting against XML External Entity attacks, XML-signature wrapping, etc.
See http://ws-attacks.org for examples of such attacks.
To make sure the content of a given resource is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and the Content-Type header should preferably include a charset.
The server should also send an X-Content-Type-Options: nosniff to make sure the browser does not try to detect a different Content-Type than what is actually sent (as this can lead to XSS).
Additionally, the client should send an X-Frame-Options: deny to protect against drag-and-drop clickjacking attacks in older browsers.
XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable and does not contain XML injection. For more information, please see the Web Service Security Cheat Sheet.
HTTP Status Codes
HTTP defines status codes. When you design your REST API, don't just use 200 for success or 404 for error.
Here are some guidelines to consider for each REST API status return code. Proper error handling may help to validate the incoming requests and better identify the potential security risks.
||Response to a successful REST API action. The HTTP method can be GET, POST, PUT, PATCH or DELETE.
||The request has been fulfilled and the resource created. A URI for the created resource is returned in the Location header.
||The request is malformed, such as a message body format error, missing headers, etc.
||Wrong or no authentication ID/password provided.
||Used when the authentication succeeded but the authenticated user doesn't have permission to the requested resource.
||When a non-existent resource is requested.
||The client presented a content type in the Accept header which is not supported by the server API.
||Method Not Allowed
||The error for an unexpected HTTP method. For example, the REST API is expecting HTTP GET, but HTTP PUT is used.
||Payload Too Large
||Used to signal that the request size exceeded the given limit, e.g. regarding file uploads and to ensure that the requests have reasonable sizes.
||Unsupported Media Type
||The requested content type is not supported by the REST service. This is especially effective when you are working primary with JSON or XML media types.
||Too Many Requests
||The error is used when there may be a DOS attack detected or the request is rejected due to rate limiting.