API Security Notes

Authentication

• 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 (HS256 or RS256).

  • Make token expiration (TTL, RTTL) as short as possible.

  • Don't store sensitive data in the JWT payload, it can be decoded easily. OAuth

  • Always validate redirect_uri server-side to allow only whitelisted URLs.

  • Always try to exchange for code and not tokens (don't allow response_type=token).

  • Use state parameter with a random hash to prevent CSRF on the OAuth authentication process.

  • Define the default scope, and validate scope parameters for each application.

Input Validation

• 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: 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. 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.

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

• Validate content-type of posted data as you accept (e.g. application/x-www-form-urlencoded, multipart/form-data, 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 (credentials, Passwords, 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. Quota, 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.

Output

• Send X-Content-Type-Options: nosniff header.

• Send X-Frame-Options: deny header.

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

• Don't return sensitive data like credentials, Passwords, or security tokens.

• Return the proper status code according to the operation completed. (e.g. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc.).

Secure Configuration

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

Brute Force & Rate Limit

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

Data Processing

• 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 UUID instead.

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

• Use a CDN for file uploads.

Logging & Monitoring

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

Known Vulnerabilities & Component Management

• Remove unused dependencies, unnecessary features, components, files, and documentation. Continuously check the versions of your dependencies for known security flaws.

-EOF