3 Oct 2022
  • Website Development

API Security Best Practices: A Decade of Insights (Expert Tips)

Start Reading
By Tyrone Showers
Co-Founder Taliferro

Below is a compiled list of best practices for securing APIs that I have picked over the last decade. I use this as a quick reference checklist that I can refer to when assessing an API. I used to have this in my Apple notes, but I think it's better here. You can also use our API certification self assessemnt tool located here

Although we offer a comprehensive API self-assessment checklist and tool, there are instances where the insight of a professional is invaluable. Discover how Taliferro Group's specialized expertise can enhance the security of your APIs. Visit us at to learn more.

  • Check certificate revocation on every call.
  • A trusted PKI issues certificates.
  • No export-grade encryption algorithms.
  • All communications from the network's edge to backends are secured using the most recent version of mutual TLS with perfect forward secrecy and a modern cipher set.
  • All communications to the network's edge are secured using the most recent version of TLS with perfect forward secrecy and a modern cipher set.
  • Authentication should include a set of claims.
  • Use the API Gateway to validate the Bearer token.
  • Ensure the API Gateway does not cache.
  • All calling applications provide an API key in the header.
  • Use an API Gateway for handling authentication.
  • Use an authentication method to authenticate access to all endpoints.
  • Use OAuth 2.0 instead of 1.0.
  • Certificate pinning or another suitable certificate protection method should be employed.
  • Ensure private keys are protected.
  • Check certificates uniquely identify a system
  • Check the certificate against the presented server names for every call.
  • Check the certificate for the validity period on every call.
  • Use encrypted, signed bearer tokens JWTs.
  • Ensure the API Gateway transmits claims to backend business logic.
  • The API Gateway is the only authorized caller to backend systems.
  • Guard for remote system impersonators.
  • Ensure the API delivery stack validates the identity of its caller.
  • Ensure the API Gateway validates JWTs.
  • Return 401 status for the authentication failure.
  • The API Gateway evaluates the calling application to authorize access to an endpoint.
  • Have the API Gateway evaluate Bearer token scope.
  • Use authorization that requires domain knowledge below the API Gateway.
  • The API Gateway provides claims to underlying systems to perform authorization.
  • Authorization results are not cached.
  • Backend systems should validate that the provider of a claim set is authorized.
  • If OAuth, users can revoke tokens without administrator assistance.
  • Return 403 for OAuth authorization failure.
  • Ensure authorization occurs early - before any business logic.
  • All code paths should require authorization.
  • Use scope claims to constrain the activities of a caller.
  • Sensitive information should not be visible in paths.
  • Sensitive information should not be visible in headers.
  • Use correlation keys requested from clients.
  • If a client does not provide a correlation key, have the API Gateway create one.
  • Encrypt context.
  • Verify content types in request bodies.
  • Reject requests that do not send accepted content.
  • Content is verified to be syntactically correct.
  • Verify content against a schema.
  • Request bodies are not directly bound to data objects.
  • Ignore properties, headers, and content if the API does not expect it.
  • Accept binary objects as base64 encoded strings.
  • Caller and endpoints should throttle.
  • Return errors in a consistent structure.
  • Do not return stack traces.
  • Response headers or bodies should not return server and platform names.
  • Do not return unnecessary information about the nature of an error.
  • Error responses should only include sufficient information for a consumer to know how to correct their request.
  • Sensitive information should not be visible in response headers.
  • Use the no-cache directive on API endpoints.
  • Use Cache-Control headers to identify stale information.
  • Disable caching.
  • Redact sensitive information.
  • Enable CORS for APIs running a browser.
  • Return HSTS headers to enforce upgrades to HTTPS on all endpoints.
  • Verify headers against a schema.
  • Responses should not contain sensitive data.
  • Parameterize SQL queries.
  • Do not use dynamic SQL in stored procedures.
  • JSON is not evaluated directly as JavaScript.
  • Do not execute binary code or script code in the body.
  • Log security events into a centralized security event system.
  • Convert exceptions to standardized errors.
  • All type shapes in the API's contract definition have clearly defined and explicit descriptions and validation patterns.
  • Have information security personnel as part of API product teams.
  • Test APIs for security flaws with penetration testing tools.
  • Test APIs with static code analysis tools.
  • Use managed code for API development.
  • Patch critical vulnerabilities immediately.
  • Use network isolation techniques.
  • Check sudden changes in API usage.
  • Only appropriate personnel can disable an API.
  • Only appropriate personnel can disable access to APIs by applications.
  • Mark data with a security classification to identify its appropriate usage.
  • As a rule, developers cannot modify code in any environment without following the standard code progression path.
  • Use automated tests.
  • Record and track technical debt.
  • Non-production endpoints should not be accessible to API consumers. Create an API inventory for review and analysis.
Tyrone Showers