API Security Best Practices

By Mark Michon

Duck and duck

While an API is essentially meant to be used, security issues can arise with an API even if its users are all internal. To address API security issues, in this article we’ve gathered a series of API best practices that we hope you’ll remember will help you in the future as you try to secure your API/Web services from intrusions.

1. Use HTTPS

The Web is not what it used to be, and standard HTTP does not meet Web security requirements. As browser vendors start flagging urls that don’t use security, your API might want to start doing the same — with HTTPS. HTTPS encrypts traffic using the Transport Layer Security protocol (TLS). This means THAT HTTPS encrypts the communication between the client and server. To the API, HTTPS means that the content sent from the API is protected by third parties, but more importantly it means that access credentials are secure.

2, certification

When it comes to access credentials, the most straightforward way to avoid accidental use of the API is to ensure proper authentication. Authentication determines whether and how you can access an API, and even free apis that are open to the outside world should theoretically be considered for an authentication strategy to ensure security. With authentication, you can limit or remove users who abuse your API, allowing users to reset their credentials as needed to keep them safe. To learn more about API authentication, read The Three Most Common Authentication Methods.

3, authorization,

A similar function to authentication is authorization. The difference between authentication and authorization is that authentication focuses on who is using the API, while authorization focuses on what they can access. For example, free plan users may be authorized to access only a subset of all of your apis. When you want to integrate apis such as social login, user authorization allows the application to read their profile data from the social platform.

4. Secure EndPoints and Resources (object level authorization)

In general, we protect endpoint/ Endpoints through authorization, but in the longer term, we need to secure individual resources. The security of a single resource prevents misconfigured endpoint level authorization to access data. In addition, it means that the endpoint itself is not limited by the type of user, but rather that resources control who can and cannot view it. (Down to URL permissions)

5, the speed limit

When we think of security, we often think of inappropriate access. Of course, how to handle inappropriate access is also useful for managing resources. Speed limiting is a technique that limits API usage. It not only protects resources economically, but also ensures that the server does not become overloaded with a single large number of requests. Most speed limiting approaches are time-based — a billing cycle is typically set to deal with overall API usage, as well as a “burst” approach to limit incoming requests. If you see the 429 HTTP status code, you are being speed-limited.

6. Validate and purify input

One of the oldest ways to attack Web programs is through input: the way we access data may have changed, but the need to validate arbitrary user input has not. Client-side validation helps prevent errors and improve the user experience, but the API also needs to validate and sanitize the input before performing an action on it — a decontaminating policy that removes malicious or invalid code from the request. Verify that the data meets the requirements that the resource expects, such as factors such as type, form, and even password structure.

7. Open as needed

It is tempting to take shortcuts to map the data model directly to the interface, but this not only results in lengthy responses and increased bandwidth usage, but also exposes data that users do not need access to. For example, a /user interface returns user information. It may only require some basic information about the user, but not the user’s password/permissions.

Error message configuration

In addition to sanitize the API’s input data, you also need to sanitize the information generated from it. Error messages are critical for users to understand that a problem has occurred, but make sure that no sensitive data is exposed. Providing end-users with detailed information about the API’s internal code structure is an advantage for attackers, so make sure that the configuration of error messages not only provides enough information to help users debug and report problems, but not enough to expose the inner workings and sensitive data of the application.

9. Don’t expose sensitive information

API openness is built on protecting sensitive data by ensuring that details are not exposed in JSON Web tokens and caches. The JWT (JSON Web Token) body gives the illusion of security and is actually quite easy to decipher. Therefore, you should avoid JTW and caches that contain user information that can be used to access your application. The same advice applies to urls, making sure the query string does not expose sensitive data details.

10. Assess dependencies

We didn’t write all of our own code during development; in most cases, a large portion of the code included libraries, middleware, and various dependencies from external sources. While we can generally assume that popular software packages are battle-tested, that doesn’t mean these dependencies are completely bug free. So make sure you evaluate the API dependencies — are they maintained well? Are you using the latest version? What are the historical issues? Perhaps the most important thing to think about is: do you really need a library to implement what you’re doing?

11. Allow users to track and reset authentication keys

Another way to improve API security is to allow users to reset their credentials and monitor usage. A common mistake is not to allow consumers to reset their API keys. This problem can now directly affect your API if API users accidentally expose their keys or obtain them maliciously. Instead, for security, you can create a way for them to manage access.

Certification in standardized services

We’ve seen API giants like Google, Microsoft, and Amazon standardize their API licensing and certification processes. Consider a centralized approach, such as using an API gateway or a dedicated entry point to handle authentication requests.

Follow the OWASP standard guide

In addition to these best practices, consider adopting the recommendations of the Open Web Application Security Project (OWASP). They provide platform-specific guidance, as well as guidance on upcoming specific apis — API Security Top 10. In addition to protecting the API at the code level, you also need to ensure that the server and infrastructure are properly configured to avoid unauthorized access.

The translator has said: the author of the last paragraph of this article has his own product, so the translator does not translate, if there is any better translation of this article, welcome to leave a message

To join HelloGitHub’s “translation also dance” series requirements:

  • Read GitHub, open source, programming, programmer information and articles in English

  • Translate or correct at least 1 article per month

  • The translation is plain and smooth

  • Understand Markdown and layout rules

Welcome to join the excellent you, let your talent dance! Share excellent articles with more people.