Skip to main content

How to best protect APIs

The world runs on APIs - from card payment systems to electric vehicles - which means that bad actors have a wide range of potential targets to attack. We offer some best practices and tips on securing your API services as well as specific settings on your Threat Protection proxies that can help defend againts API based attacks.

General Tips

  1. Always use TLS. Always.
  2. Use DDoS and rate-limiting to prevent availability attacks where malicious actors attempt to overwhelm your system and make it unresponsive to all users.
  3. Prevent the most prevalent types of web application attacks by following OWASP API security best practices.
  4. Protect all restricted endpoints via authentication and authorization (e.g. OAuth2, OIDC, WebAuthn, API Keys, etc.)
    1. Authentication lets you know if the user is registered and legitimate if they present the right set of credentials (i.e. who they are
    2. Authorization defines the level of access given to a user (i.e. what they can do)
  5. If using API keys, ensure that keys are scoped to limited functionality. Avoid issuing keys with full admin access.
    1. This helps prevent accidents or unintended data exposure to anyone that can access the key.
    2. Furthermore, if any API key is compromised an attacker can only perform operations in scope for that key - i.e. you minimize the blast radius.
    3. Practice API key rotation as often as possible to avoid long-lived keys. The longer a key is valid, the higher the chances it will be exposed to an attacker.
  6. When API errors occur, provide helpful information to the client that is neither too vague (“Internal Server Error” vs “Filed to retrieve user data. Please check that you are authenticated and have sufficient permissions”) nor too revealing (e.g. “SQL query failed due to malformed input containing a DROP TABLE command” vs “Invalid input provided. Please review and try again”). See this thorough article from Postman on more detailed tips.
    1. Never return full stack traces as it can too much insight to attackers on how your system works internally (e.g. what framework you use and its version can usually be determined which can then easily be cross-referenced against a database of known vulnerabilities for said framework version).
    2. Return proper response codes as they relate to the client, for example 4xx status codes should result from user input errors whereas 5xx indicate server errors. 5xx errors should be minimized in your applications as they tend to be catch-all responses to unexpected server behaviour which isn’t great for user experience, and also reveals how your application can be made to break.
  7. Validate all input at the API level to prevent major attack vectors such as SQL injection or Cross-Site Scripting (XSS). The Threat Protection WAF is great at detecting input based attacks but should be used in addition to safe input handling and validation as there can also be attacks that exploit the nature of your application (e.g. allowing negative input values that lets customers credit their accounts when that should never be allowed).