API Pre Go-live
Does your API use standard authentication like JWT, Oauth
Do not use Basic auth as your authentication mechanism. Basic Authentication is the simplest form of HTTP authentication. With each request, users submit their credentials as plain and potentially unencrypted HTTP fields. Read about JWT at https://jwt.io/ and Oauth at https://oauth.net/ to learn more.
JWT token doesn't store any sensitive or identifying information
Ensure that your jwt token should not store identifying information like user passwords, account ids, credit card related information or any such parameters which can be used in reverse-engineering. One common mistake we make is to put database ids in such token, which a malicious actor uses to run a loop and see if they can sneak in.
Do you use a random complicated key (JWT Secret) to make brute forcing the token very hard?
Do not make it easy for the bad actors to guess the algorithrm behind the token generation.
Ensure that the authentication token expires
Your authentication tokens should have an expiration date and time.
Ensure that the entire traffic between your client and server and also within various components within your own servers (db, web, cache etc) is encrypted.
API doesn't return sensitive information about the user
A common mistake seen is object.to_json which ends up sending all the columns of that entity. Now there are certain objects like user which could contain fields like password, salt and other sensitive information which should not be passed under any condition.
Don't return sensitive data like credentials, Passwords, or security tokens.
Is user input validated?
API endpoints which require authenticated, do they ensure that?
Ensure timely review is done especially when a new endpoint is being released to make sure these are following the required authentication logic.
Use HTTPS on server side to avoid MITM (Man in the Middle Attack).
Use HSTS header with SSL to avoid SSL Strip attack.
Avoid Using Auto-Incrementing IDs. Use UUID instead.
Auto-incrementing IDs make it trivial for attackers to guess the URL of resources they may not have access to. Instead, use universally unique identifiers (UUID) to identify resources.
Limit requests (Throttling) to avoid DDoS / brute-force attacks.
If you are dealing with huge amount of data, use Workers and Queues to process as much as possible in background and return response fast to avoid HTTP Blocking.
Use the proper HTTP method according to the operation:
GET (read), POST (create), PUT/PATCH (replace/update), and DELETE (to delete a record), and respond with 405 Method Not Allowed if the requested method isn't appropriate for the requested resource.
Validate content-type on request Accept header
(Content Negotiation) to allow only your supported format (e.g. application/xml, application/json, etc.) and respond with 406 Not Acceptable response if not matched.
If you are parsing XML files, make sure entity parsing is not enabled to avoid XXE (XML external entity attack).
If you are parsing XML files, make sure entity expansion is not enabled to avoid Billion Laughs/XML bomb via exponential entity expansion attack.
Send X-Content-Type-Options: nosniff header.
To read more about this header see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
Send X-Frame-Options: deny header.
To read more about this header see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
Send Content-Security-Policy: default-src 'none' header.
Remove fingerprinting headers - X-Powered-By, Server, X-AspNet-Version, etc.
Force content-type for your response. If you return application/json, then your content-type response is application/json.
Return the proper status code according to the operation completed. (e.g. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc.).