Taliferro › Blog

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

By Tyrone Showers

Co-Founder Taliferro

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

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 https://api-certification.taliferro.com.

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 https://taliferro.com/api-design-services 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

Want this fixed on your site?

Tell us your URL and what feels slow. We’ll point to the first thing to fix.

Need help?
Tell us what feels slow. We’ll point to the fix.