• API Pre Go Live Checklist

If you have API, follow this checklist to ensure that they are secure and do not fall victim to malicious users.

Authentication

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.

Data Security

Encrypt everything
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.

Data validation

Is user input validated?
Even if your UI is validating user input, your API should be guarding the quality of data going inside the database. This also avoids common vulnerabilities (e.g. XSS, SQL-Injection, Remote Code Execution, etc.). - SQL Injection: A user submits a malicious database query as input. If the application passes input directly to a database, the database will run the query. - Remote Code Execution: A user submits a command as input. If the application passes input directly to a shell or external application, the server will run the command. - Cross-Site Scripting (XSS): A user submits JavaScript as input. If a browser renders the field containing this JavaScript, the browser will execute the code.

Security

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.

Stability

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.

Standards

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.

Output

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.).

Sources

https://github.com/shieldfy/API-Security-Checklist
https://www.templarbit.com/blog/2018/01/10/api-security-checklist/

Help Us Improve!

If you have any suggestions to improve this checklist, please let us know by filling out this form.