API Security

6 mins read

Checklist of the most important security countermeasures when designing, testing, and releasing your API.

Authentication

  •  Don’t use Basic Auth. Use standard authentication instead (e.g., JWTOAuth).
  •  Don’t reinvent the wheel in Authenticationtoken generationpassword storage. Use the standards.
  •  Use Max Retry and jail features in Login.
  •  Use encryption on all sensitive data.

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 (TTLRTTL) as short as possible.
  •  Don’t store sensitive data in the JWT payload, it can be decoded easily.
  •  Avoid storing too much data. JWT is usually shared in headers and they have a size limit.

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.

Access

  •  Limit requests (Throttling) to avoid DDoS / brute-force attacks.
  •  Use HTTPS on server side with TLS 1.2+ and secure ciphers to avoid MITM (Man in the Middle Attack).
  •  Use HSTS header with SSL to avoid SSL Strip attacks.
  •  Turn off directory listings.
  •  For private APIs, allow access only from whitelisted IPs/hosts.

Input

  •  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/xmlapplication/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-urlencodedmultipart/form-dataapplication/json, etc.).
  •  Validate user input to avoid common vulnerabilities (e.g., XSSSQL-InjectionRemote Code Execution, etc.).
  •  Don’t use any sensitive data (credentialsPasswordssecurity tokens, or API keys) in the URL, but use standard Authorization header.
  •  Use only server-side encryption.
  •  Use an API Gateway service to enable caching, Rate Limit policies (e.g., QuotaSpike Arrest, or Concurrent Rate Limit) and deploy APIs resources dynamically.

Processing

  •  Check if all the endpoints are protected behind authentication to avoid broken authentication process.
  •  User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders.
  •  Don’t auto-increment IDs. Use UUID instead.
  •  If you are parsing XML data, make sure entity parsing is not enabled to avoid XXE (XML external entity attack).
  •  If you are parsing XML, YAML or any other language with anchors and refs, make sure entity expansion is not enabled to avoid Billion Laughs/XML bomb via exponential entity expansion attack.
  •  Use a CDN for file uploads.
  •  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.
  •  Do not forget to turn the DEBUG mode OFF.
  •  Use non-executable stacks when available.

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-ByServerX-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 credentialspasswords, or security tokens.
  •  Return the proper status code according to the operation completed. (e.g., 200 OK400 Bad Request401 Unauthorized405 Method Not Allowed, etc.).

CI & CD

  •  Audit your design and implementation with unit/integration tests coverage.
  •  Use a code review process and disregard self-approval.
  •  Ensure that all components of your services are statically scanned by AV software before pushing to production, including vendor libraries and other dependencies.
  •  Continuously run security tests (static/dynamic analysis) on your code.
  •  Check your dependencies (both software and OS) for known vulnerabilities.
  •  Design a rollback solution for deployments.


 $ 36.8   36.1   7.4