Production Best Practices: Security生产最佳做法：安全

Overview概述

The term “production” refers to the stage in the software lifecycle when an application or API is generally available to its end-users or consumers. 术语“生产”是指软件生命周期中的一个阶段，当应用程序或API通常可供其最终用户或消费者使用时。In contrast, in the “development” stage, you’re still actively writing and testing code, and the application is not open to external access. 相反，在“开发”阶段，您仍然在积极编写和测试代码，并且应用程序不向外部访问开放。The corresponding system environments are known as production and development environments, respectively.相应的系统环境分别称为生产环境和开发环境。

Development and production environments are usually set up differently and have vastly different requirements. 开发和生产环境的设置通常不同，需求也大不相同。What’s fine in development may not be acceptable in production. 开发中的好东西在生产中可能是不可接受的。For example, in a development environment you may want verbose logging of errors for debugging, while the same behavior can become a security concern in a production environment. 例如，在开发环境中，您可能需要详细记录错误以进行调试，而在生产环境中，相同的行为可能会成为安全问题。And in development, you don’t need to worry about scalability, reliability, and performance, while those concerns become critical in production.在开发中，您不需要担心可伸缩性、可靠性和性能，而这些问题在生产中变得至关重要。

Note: If you believe you have discovered a security vulnerability in Express, please see Security Policies and Procedures.如果您认为在Express中发现了安全漏洞，请参阅安全策略和过程。

Security best practices for Express applications in production include:生产中Express应用程序的安全最佳做法包括：

Don’t use deprecated or vulnerable versions of Express不要使用已弃用或易受攻击的Express版本

Express 2.x and 3.x are no longer maintained. Express 2.x和3.x不再维护。Security and performance issues in these versions won’t be fixed. 这些版本中的安全性和性能问题不会得到修复。Do not use them! If you haven’t moved to version 4, follow the migration guide.不要使用它们！如果尚未移动到版本4，请遵循迁移指南。

Also ensure you are not using any of the vulnerable Express versions listed on the Security updates page. 还要确保您没有使用“安全更新”页面上列出的任何易受攻击的Express版本。If you are, update to one of the stable releases, preferably the latest.如果是，请更新到稳定版本之一，最好是最新版本。

Use TLS

If your app deals with or transmits sensitive data, use Transport Layer Security (TLS) to secure the connection and the data. This technology encrypts data before it is sent from the client to the server, thus preventing some common (and easy) hacks. Although Ajax and POST requests might not be visibly obvious and seem “hidden” in browsers, their network traffic is vulnerable to packet sniffing and man-in-the-middle attacks.

You may be familiar with Secure Socket Layer (SSL) encryption. TLS is simply the next progression of SSL. In other words, if you were using SSL before, consider upgrading to TLS. In general, we recommend Nginx to handle TLS. For a good reference to configure TLS on Nginx (and other servers), see Recommended Server Configurations (Mozilla Wiki).

Also, a handy tool to get a free TLS certificate is Let’s Encrypt, a free, automated, and open certificate authority (CA) provided by the Internet Security Research Group (ISRG).

Use Helmet

Helmet can help protect your app from some well-known web vulnerabilities by setting HTTP headers appropriately.通过适当设置HTTP头，可以帮助保护您的应用程序免受一些已知的web漏洞的攻击。

Helmet is actually just a collection of smaller middleware functions that set security-related HTTP response headers:头盔实际上只是一组较小的中间件函数，用于设置与安全相关的HTTP响应头：

Install Helmet like any other module:

$ npm install --save helmet

Then to use it in your code:

// ...

var helmet = require('helmet')
app.use(helmet())

// ...

At a minimum, disable X-Powered-By header至少禁用X-Powered-By标头

If you don’t want to use Helmet, then at least disable the X-Powered-By header. Attackers can use this header (which is enabled by default) to detect apps running Express and then launch specifically-targeted attacks.攻击者可以使用此标头（默认情况下已启用）检测运行Express的应用程序，然后发起特定目标的攻击。

So, best practice is to turn off the header with the app.disable() method:因此，最佳做法是使用app.disable()方法关闭标题：

app.disable('x-powered-by')

If you use helmet.js, it takes care of this for you.如果您使用helmet.js，它会为您解决这个问题。

Note: Disabling the X-Powered-By header does not prevent a sophisticated attacker from determining that an app is running Express. 注意：禁用X-Powered-By标头不会阻止老练的攻击者确定某个应用程序正在运行Express。It may discourage a casual exploit, but there are other ways to determine an app is running Express.它可能会阻止偶然利用漏洞，但有其他方法可以确定应用程序正在运行Express。

Use cookies securely安全地使用cookies

To ensure cookies don’t open your app to exploits, don’t use the default session cookie name and set cookie security options appropriately.为确保cookie不会打开应用程序进行攻击，请不要使用默认会话cookie名称，并适当设置cookie安全选项。

There are two main middleware cookie session modules:有两个主要的中间件cookie会话模块：

The main difference between these two modules is how they save cookie session data. The express-session middleware stores session data on the server; it only saves the session ID in the cookie itself, not session data. By default, it uses in-memory storage and is not designed for a production environment. In production, you’ll need to set up a scalable session-store; see the list of compatible session stores.

In contrast, cookie-session middleware implements cookie-backed storage: it serializes the entire session to the cookie, rather than just a session key. Only use it when session data is relatively small and easily encoded as primitive values (rather than objects). Although browsers are supposed to support at least 4096 bytes per cookie, to ensure you don’t exceed the limit, don’t exceed a size of 4093 bytes per domain. Also, be aware that the cookie data will be visible to the client, so if there is any reason to keep it secure or obscure, then express-session may be a better choice.

Using the default session cookie name can open your app to attacks. 使用默认会话cookie名称可以打开应用程序，使其遭受攻击。The security issue posed is similar to X-Powered-By: a potential attacker can use it to fingerprint the server and target attacks accordingly.所带来的安全问题类似于X-Powered-By：潜在的攻击者可以使用它来对服务器进行指纹识别，并相应地将攻击作为目标。

To avoid this problem, use generic cookie names; for example using express-session middleware:要避免此问题，请使用通用cookie名称；例如，使用express会话中间件：

var session = require('express-session')
app.set('trust proxy', 1) // trust first proxy
app.use(session({
  secret: 's3Cur3',
  name: 'sessionId'
}))

Set the following cookie options to enhance security:

Here is an example using cookie-session middleware:

var session = require('cookie-session')
var express = require('express')
var app = express()

var expiryDate = new Date(Date.now() + 60 * 60 * 1000) // 1 hour
app.use(session({
  name: 'session',
  keys: ['key1', 'key2'],
  cookie: {
    secure: true,
    httpOnly: true,
    domain: 'example.com',
    path: 'foo/bar',
    expires: expiryDate
  }
}))

Prevent brute-force attacks against authorization

Make sure login endpoints are protected to make private data more secure.

A simple and powerful technique is to block authorization attempts using two metrics:

  1. The first is number of consecutive failed attempts by the same user name and IP address.
  2. The second is number of failed attempts from an IP address over some long period of time. For example, block an IP address if it makes 100 failed attempts in one day.

rate-limiter-flexible package provides tools to make this technique easy and fast. You can find an example of brute-force protection in the documentation

Ensure your dependencies are secure

Using npm to manage your application’s dependencies is powerful and convenient. But the packages that you use may contain critical security vulnerabilities that could also affect your application. The security of your app is only as strong as the “weakest link” in your dependencies.

Since npm@6, npm automatically reviews every install request. Also you can use ‘npm audit’ to analyze your dependency tree.

$ npm audit

If you want to stay more secure, consider Snyk.

Snyk offers both a command-line tool and a Github integration that checks your application against Snyk’s open source vulnerability database for any known vulnerabilities in your dependencies. Install the CLI as follows:

$ npm install -g snyk
$ cd your-app

Use this command to test your application for vulnerabilities:

$ snyk test

Use this command to open a wizard that walks you through the process of applying updates or patches to fix the vulnerabilities that were found:

$ snyk wizard

Avoid other known vulnerabilities

Keep an eye out for Node Security Project or Snyk advisories that may affect Express or other modules that your app uses. In general, these databases are excellent resources for knowledge and tools about Node security.

Finally, Express apps - like any other web apps - can be vulnerable to a variety of web-based attacks. Familiarize yourself with known web vulnerabilities and take precautions to avoid them.

Additional considerations

Here are some further recommendations from the excellent Node.js Security Checklist. Refer to that blog post for all the details on these recommendations: