One of the features in RestCase is that it scans your API definitions for both Security and Quality issues and shows insights about them.
We managed to scan about 50 public APIs and aggregated the results in order to write about the top 5 security issues and how to solve them.
1. Not using SSL - Use HTTPS and not HTTP.
The web has moved past standard HTTP. With browser vendors flagging URLs that don't use a secure layer, it's time to do the same for your API.
HTTPS uses Transport Layer Security (TLS) to encrypt traffic. This means communication between the client and server is encrypted.
For your API, this means the content sent from your API is secured from third-parties, but more importantly it means that the access credentials are secured.
2. Authorization in custom header with Caching.
Many of the API are using custom authorization headers but forget to set the caching to false = "Cache-control: no-cache". Web servers knows not to cache the responses when they get an Authorization header, since it may cause a data leak. Consider the following: One is calling a REST API with X-Auth (custom) header for Resource A, and another is doing the same call. The web server may respond with the details of the first call since it is already cached.
This is why it is critical to specify "Cache-control: no-cache" when using custom header for authorization.
HTTP defines a powerful caching mechanism that include ETag, If-Modified-Since header, and 304 Not Modified response code. They allow your clients and servers to negotiate always a fresh copy of the resource and through caching or proxy servers increase you application's scalability and performance.
3. Rate limit
When we think of security, we often think of inappropriate access. It can also be useful to think of API security as managing resources. Rate-limiting is a technique for throttling the usage of an API. It can protect your resources financially, but also ensure that your servers aren't overloaded by a flood of requests at one time.
Many rate-limiting approaches are time-based. They can be set for a billing period to handle overall usage, as well as use a "burst" approach to limit large influxes of requests.
It is advised to add a rate limit to your API for all API calls and in case the limit is reached to return a 429 HTTP status code.
It is advised to add these 3 headers to all the API responses:
1. X-Rate-Limit: 700 (number of allowed requests in the current period)
2. X-Rate-Limit-Remaining: 699 (number of remaining requests in the current period)
3. X-Rate-Limit-Reset: 92 (number of seconds left in the current period until the rate limit resets)
4. Input Validation
API parameters are little holes into your application where malicious users can throw all sorts of rubbish in. They want to compromise your application and all the lovely data held within.
If you’re expecting a date string, make sure it fits the format you’re expecting. If you’re expecting a boolean, reject the request immediately if you get anything except one.
Use enum’s to limit the number of responses an input is allowed to be. If you’re expecting a number, make sure it’s a god-damn number.
The same goes for content-type. Anything that is passed to the API, be it header or body, has to be validated that it’s a permitted value, or a kind of value you’re expecting.
5. Input Sanitization
Ok, so by using input validation we’ve made sure we’re getting the right kind of variables passed in to our API. But we can’t trust this data quite yet.
Sanitise that data! Make sure you’re not allowing anything malicious through. You must filter out anything which you don’t expect, or want in there.
Does your API allow HTML content to be passed through? You’ve got to strip out any javascript you find in there, as that could be part of a Cross Site Scripting (XSS) attack. You should also parse HTML to make sure it won’t break any pages it’s inserted into.
Sanitize any and all text, think usernames, addresses, anything. It could contain javascript, or even worse SQL or operating system commands.
Once that stuff gets into your system you never know it won’t get invoked somewhere. Strip it all out on the way in so that it will not be able to do any harm on the way out.
Summary
Please, use the Authorization header and not a custom header for passing authorization data.
Input validation and sanitization is very important in order to keep your API secured. Specifically, validate everything your application will be handling, before it gets anywhere it could do any damage and sanitize all input before acting on it.
I really recommend to sign-up for RestCase (it is free), upload your OpenAPI specification and see the Quality and Security Insights.