API security breaches have been skyrocketing recently. API attacks have risen over 400% in less than a year. To make matters worse, over 80% of those attacks occur via authenticated endpoints. In short, API security has never been more important.

Shieldly recently posted a massive list of API security concerns to their GitHub. It’s an excellent starting point for a thorough, comprehensive API security checklist. Beginning with these guidelines, we’ve done additional digging to gather as many potential API security concerns as possible to create a helpful API security checklist.

Authentication

If you’re using the Basic Auth protocol in your API, consider changing it. Basic Auth can be abused as laid out by CAPEC-114. Instead of Basic Auth, you should consider using an authentication solution like JSON Web Tokens instead.

There’s no need to recreate or try to improve on standard flows like authentication, token generation, or password storage, either. They’re widely used, so the bugs have already been worked out. Modifying them just increases the risk of vulnerabilities.

Also, when working with sensitive data, you should have some encryption solution in place. All API communications should feature either an SSL connection or a TLS encryption like HTTPS.

Use JWTs Properly

JSON Web Tokens are useful as access and refresh tokens. JWTs are not as secure as other security solutions, though. JWT data is often too transparent and easily accessed by third-party applications. To make matters worse, API consumers can begin to rely on the data inside a JWT rather than proper implementation in their own code.

For external and third-party applications, it’s better to use opaque tokens instead. If you still want to take advantage of JWTs and opaque tokens, a phantom token or split token approach is more secure and preferable.

There are other ways to make sure a JWT is secure, as well.

Only asymmetric algorithms should be used, for one thing, which pairs with a public API key which is then used to verify a private key. Use modern protocols, like edDSA, ES256, or PS256, whenever possible. Only resort to older asymmetrical solutions like RS256 when there are technical considerations restricting your security options.

Lastly, make sure to store data sparingly in JWTs. They’re rather limited in size since they’re usually transmitted via a header.

Use OAuth Properly

Don’t let individual APIs or API gateways issue access or refresh tokens. Instead, use a central OAuth server, as issuing tokens is complicated. Each authorization stage requires unique data, so it’s better to have a central server handle all of that for you. Furthermore, making each API and gateway able to issue tokens makes it challenging to keep track of all of the authorized credentials, which can quickly get out of hand.

You should ensure that you always validate redirect_uri on the server side and that it always points to trusted resources. Applications should not use the implicit flow that returns tokens directly to the client. Instead, use the code flow that introduces the intermediary step of receiving an authorization code that is then exchanged for tokens. Also, always use the code flow with the Proof Key for Code Exchange extension. This helps to prevent cross-site request forgery (CSRF), which can lead to all manner of authorization and authentication vulnerabilities.

Also, implement OAuth scopes to restrict the access of API tokens. This significantly inhibits the power of illicit users who get a hold of credentials. Checking these API token scopes at the gateway will greatly reduce the amount of malicious traffic that reaches your API. Token scopes should be used for coarse-level verification, such as evaluating a request with a given token authorized to call a given endpoint.

Proper Authorization Inputs

For each endpoint, you should conduct a survey and assess which HTTP methods are allowed and how each endpoint responds to particular requests. Check to see if privilege escalation is possible. For instance, see if the Content-Type header can be changed when switching from application/xml to application/json or via a POST request, making it vulnerable to protocol manipulation.

To avoid injection attacks, you’ll want to implement input validation for all data fields and properties sent to the server. Also, check to ensure no sensitive data, like user names or passwords, are visible in the URL. Ensure that HTTP Parameter Pollution isn’t possible, by including the same parameter twice in one request using different values and seeing how your API responds.

Finally, if you’re using an API gateway for caching and rate limiting, you’ll want to make sure it can’t be bypassed with the API endpoint being directly available, resulting in a functionality bypass. This is a common error for microservices and serverless functions.

Process APIs Appropriately

There are a number of other ways developers should process their APIs to limit security issues. Here are some other points to check:

• Map out which of your endpoints are properly protected against Broken Object Level Authorization, preventing any Adversary-in-the-Middle attacks.
  *Check to ensure that IDs are also attributed randomly and not incrementally. If your API parses XML data, ensure it’s not vulnerable to XML external entity (XXE) attacks.
• Make sure that entity expansion is activated, too, to prevent resource starvation via attacks like Billion Laughs or XML Bombs, preventing exponential data expansion.
• Check to see if any areas where uploading is possible can be abused.

Implement Output Properly

You’ll want to make sure your API returns the right resources. You’ll also want to include the following headers to ensure your API’s payloads are returned properly, safely, and securely.

API Output Headers

• X-Content-Type-Options: nosniff
• X-Frame-Options: deny
• Content-Security-Policy: default-src ‘none’

Make sure to remove headers that fingerprint your API, like X-Powered-By, Server, X-AspNet-Version, for instance. Restrict sensitive data that can be returned, too, like User IDs or passwords. Finally, ensure your API returns the proper status codes for each operation, like 200 OK or 400 Bad Request.

CI/CD and Monitoring

In your CI/CD pipeline, make sure you have an auditing system in place and aren’t just relying on self-approval. You’ll want to ensure that each component, including libraries, third-party tools, and dependencies, is analyzed and secure. You’ll also want to continuously run either static or dynamic analysis of your code. Finally, it’s a good idea to create a rollback point before deploying any new CI/CD systems.

When monitoring your APIs, check that all services and components use a centralized log. You should watch all incoming requests, errors, and responses and keep a record if possible. It’s good to avoid logging sensitive data like usernames or passwords, though, so you’ll need to put some redaction solution in place. It’s also recommended to set alerts to be sent via SMS, Slack, Telegram, Email, or whatever messaging platform you prefer.

Document and Catalog Your API

It’s far too easy to lose track of your API, especially during development. You might create an endpoint for testing purposes and then never use it again, causing you to forget its existence. Lost or disorganized API resources can result in API sprawl, zombie APIs, shadow APIs, and all manner of vulnerable, exposed surface areas.

Keeping an active inventory of your APIs provides a thorough map of your entire API ecosystem. This is invaluable for testing your API security. You can even use this documentation as part of your automated security testing system.

Final Thoughts on API Security Checklist

You need to know that your API is secure for your customer’s sake and your own peace of mind. API usage is a contract that demands trust from all sides. Your users and customers trust you with their most sensitive data, while you, in turn, trust your users not to abuse your resources and services. Any breach of that trust on either side brings the whole thing down.

Following this API security checklist will help you make sure your APIs are as airtight and invulnerable as possible. It’ll also help get you thinking systemically, which is even more important than the checklist itself.