Comment on page
API Security Notes
- Drop Basic Authentication. Use more secure authentication types such as JWT or OAuth. Because, in basic authentication, with each request, users submit their credentials as plain and potentially unencrypted HTTP fields. For more information about secure JWT usage.
- Never try to implement your own authentication, token generation, or password storage methods. Depending on your application’s language or framework, chances are there are existing solutions with proven security. Review the language or framework documentation to learn how to implement these solutions.JWT (JSON Web Token)
- Use a random complicated key (
JWT Secret) to make brute forcing the token very hard.
- Don't extract the algorithm from the header. Force the algorithm in the backend (
- Make token expiration (
RTTL) as short as possible.
- Always validate
redirect_uriserver-side to allow only whitelisted URLs.
- Always try to exchange for code and not tokens (don't allow
stateparameter with a random hash to prevent CSRF on the OAuth authentication process.
- Define the default scope, and validate scope parameters for each application.
- Malformed user input is the cause of some the most common vulnerabilities on the web, including: SQLi, RCE, XSS. Validate the all inputs comes from user.
- Use the proper HTTP method according to the operation:
PUT/PATCH (replace/update), and
DELETE (to delete a record), and respond with
405 Method Not Allowedif the requested method isn't appropriate for the requested resource. Any operations that don’t match those methods should return 405 Method Not Allowed. This prevents users from accidentally (or intentionally) performing the wrong action by using the wrong method.
content-typeon request Accept header (Content Negotiation) to allow only your supported format (e.g.
application/json, etc.) and respond with
406 Not Acceptableresponse if not matched.
content-typeof posted data as you accept (e.g.
application/json, etc.). Also, determine one content type and use it in all requests as a best practice. And don't accept other types.
- Don't use any sensitive data (
security tokens, or
API keys) in the URL and header even in POST request, but use standard Authorization header.
- Use an API Gateway service to enable caching, Rate Limit policies (e.g.
Spike Arrest, or
Concurrent Rate Limit) and deploy APIs resources dynamically.
- Ensure that all components of your services are statically scanned by AV software before pushing to production, including vendor libraries and other dependencies.
Content-Security-Policy: default-src 'none'header.
- Remove fingerprinting headers -
content-typefor your response. If you return
application/json, then your
- Don't return sensitive data like
- Return the proper status code according to the operation completed. (e.g.
400 Bad Request,
405 Method Not Allowed, etc.).
- Use HSTS header with SSL against SSL Strip attack.
- Use HTTPS on server side to avoid MITM (Man in the Middle Attack).
- Turn debug mode off before deployment. Because, any attacker can trigger the debug mode and s/he can learn any important data about the API / System.
- Make sure that all endpoints with access to sensitive data require authentication. This prevents unauthenticated users from accessing secure areas of the application and perform actions as anonymous users.
- Attackers will try to authenticate using a variety of credential combinations. Setting a maximum number of retries blocks users who fail too many authentication attempts in a certain amount of time. Users who exceed the number of max retries are placed in a “jail” which prevents further login attempts from their IP address until a certain amount of time passes. So, limit requests (Throttling) to avoid DDoS / brute-force attacks.
- Instead of forcing the client to wait, consider processing the data asynchronously against race condition and large process amount.
- Don't auto-increment IDs. Use
- 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 bombvia exponential entity expansion attack.
- Use a CDN for file uploads.
- Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis. Logs that are generated should be in a format that can be easily consumed by a centralized log management solution.
- Remove unused dependencies, unnecessary features, components, files, and documentation. Continuously check the versions of your dependencies for known security flaws.