Skip to main content

API Security Checklist

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

Authentication

  • Don’t useBasic Auth. Use standard authentication instead (e.g.,JWT).
  • Don’t reinvent the wheel inAuthentication,token generation,password storage. Use the standards.
  • UseMax 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 orRS256).
  • Make token expiration (TTL,RTTL) as short as possible.
  • Don’t store sensitive data in the JWT payload, it can be decodedeasily.
  • Avoid storing too much data. JWT is usually shared in headers and they have a size limit.

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).
  • UseHSTS header with SSL to avoid SSL Strip attacks.
  • Turn off directory listings.
  • For private APIs, allow access only from whitelisted IPs/hosts.

Authorization OAuth

  • Always validateredirect_uri server-side to allow only whitelisted URLs.
  • Always try to exchange for code and not tokens (don’t allowresponse_type=token).
  • Usestate parameter with a random hash to prevent CSRF on the OAuth authorization process.
  • Define the default scope, and validate scope parameters for each application.

Input

  • Use the proper HTTP method according to the operation:GET (read),POST (create),PUT/PATCH (replace/update), andDELETE (to delete a record), and respond with405 Method Not Allowed if the requested method isn’t appropriate for the requested resource.
  • Validatecontent-type on request Accept header (Content Negotiation) to allow only your supported format (e.g.,application/xml,application/json, etc.) and respond with406 Not Acceptable response if not matched.
  • Validatecontent-type of posted data as you accept (e.g.,application/x-www-form-urlencoded,multipart/form-data,application/json, etc.).
  • Validate user input to avoid common vulnerabilities (e.g.,XSS,SQL-Injection,Remote Code Execution, etc.).
  • Don’t use any sensitive data (credentials,Passwords,security tokens, orAPI 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.,Quota,Spike Arrest, orConcurrent 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. UseUUID instead.
  • If you are parsing XML data, make sure entity parsing is not enabled to avoidXXE (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 avoidBillion 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

  • SendX-Content-Type-Options: nosniff header.
  • SendX-Frame-Options: deny header.
  • SendContent-Security-Policy: default-src ‘none’ header.
  • Remove fingerprinting headers –X-Powered-By,Server,X-AspNet-Version, etc.
  • Forcecontent-type for your response. If you returnapplication/json, then yourcontent-type response isapplication/json.
  • Don’t return sensitive data likecredentials,passwords, orsecurity 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.).

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.

Monitoring

  • Use centralized logins for all services and components.
  • Use agents to monitor all traffic, errors, requests, and responses.
  • Use alerts for SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.
  • Ensure that you aren’t logging any sensitive data like credit cards, passwords, PINs, etc.
  • Use an IDS and/or IPS system to monitor your API requests and instances.

NOTE: Special Thanks to for the API Security Checklist