摘要：前言这将是一个分为两部分，内容是关于在生产环境下，跑应用的最佳实践。潜在的攻击者可以通过它们进行针对性的攻击。
前言
这将是一个分为两部分，内容是关于在生产环境下，跑Express应用的最佳实践。第一部分会关注安全性，第二部分最会关注性能和可靠性。当你读这篇文章时，假设你已经对Node.js和web开发有所了解，并且对生产环境有了概念。
概览生产环境，指的是软件生命循环中的某个阶段。当一个应用或API已经被它的终端用户所使用时，它便处在了生产环境。相反的，在开发环境下，你任然在不断得修改和测试代码，应用也不能被外部所访问。
开发环境和生产环境经常有很大的配置上的和要求上的不同。一些在开发环境下可以使用的东西，在生产环境下，它们不一定是能够被接受的。例如，在开发环境下，我们需要详细的错误日志信息来帮助我们debug，而在生产环境下，这则会带来安全隐患。又比如，在开发环境下，你不必考虑可伸缩性和可靠性还有性能的问题，但这些在生产环境下都非常重要。
以下是将Express应用部署于生产环境中的一些安全性方面的最佳实践。
不要使用被弃用或不可靠的Express版本Express 2.x 和 3.x 已经不再被维护了。这些版本上的安全和性能问题都将不会被修复。所以不要使用它们！如果你还没有迁移至Express 4，可以参考这份迁移指南。
同时也保证不要使用在安全更新列表中列出的这些不可靠版本的Express。如果你不巧使用了，请升级至稳定版，最好是最新版。
使用TLS如果你的应用需要处理或传输敏感数据，请使用TLS来确保连接和信息的安全。这项技术会在数据被从客户端发出前加密它。尽管Ajax和POST请求中发出的数据看上去并不可见，但它们的网络环境仍可以被嗅探和进行中间人攻击。
你可能已经对SSL加密有所了解。TLS是进化版的SSL。换句话说，如果你正在使用SSL，请更新成使用TLS。大多数情况下，我们推荐使用Nginx来处理TLS。关于如何在Nginx（或其他服务器）上配置TLS，请参考推荐的服务器配置（Mozilla Wiki）。
另外，有一个可以很方便地取得TLS证书的工具是Let’s Encrypt。它是一个免费的，自动化的，开放的CA。由ISRG提供。
使用HelmetHelmet通过适当地设置一些HTTP头，来帮助你的应用免受一些广为人知的web攻击。
Helmet其实就是九个设置与安全相关的HTTP头的中间件的集合：
csp 设置了Content-Security-Policy头来帮助抵挡跨站脚本攻击和其他跨站注入。
hidePoweredBy 移除了X-Powered-By头。
hpkp 添加了Public Key Pinning头来抵挡使用伪造证书的中间人攻击。
hsts 设置了Strict-Transport-Security头来强制使用安全连接。
ieNoOpen 为IE8+设置了X-Download-Options头。
noCache 设置了Cache-Control和Pragma头来禁止客户端缓存。
noSniff 设置了X-Content-Type-Options头来阻止浏览器进行MIME嗅探。
frameguard 设置了X-Frame-Options头来提供对点击劫持的保护。
xssFilter 设置了X-XSS-Protection头来启用大多数现代浏览器中的XSS过滤器。
安装Helmet的过程和其他模块没有什么两样：
$ npm install --save helmet
然后像其他中间件一样使用它：
...
var helmet = require("helmet");
app.use(helmet());
...
至少至少，你需要禁用X-Powered-By头
如果你不想使用Helmet，那么你至少需要禁用X-Powered-By头。攻击者可以利用这个头（默认被启用）来了解到你的应用是一个Express应用，然后进行有针对性的攻击。
所以，最佳实践是使用app.disable()关闭这个头：
app.disable("x-powered-by");
如果你使用了Helmet，则它会帮你完成这件事。
安全地使用cookies确保不要让cookies暴露了你应用的信息。不要使用默认的session cookie名，并且要配置好cookie的安全选项。
Express中有两个主要的cookie session中间件模块：
express-session 代替了Express 3.x中内建的express.session中间件。
cookie-session 代替了Express 3.x中内建的express.cookieSession中间件。
这两个模块的主要区别是它们存储cookie session的方式。express-session在服务端存储session信息。它只在cookie中存储session ID，而不是session数据。默认情况下，它使用内存存储，在生产环境下，你需要自己配置可伸缩的session-store。以下是一个session-store的列表。
相反地，cookie-session中间件则把数据都存储在了cookie中：它将整个session序列化至cookie，而不仅仅是一个session ID。请仅仅在session数据很小且被早早得加密过时才使用它。浏览器支持的每个cookie的大小通常最多是4093B。所以请确保不要超过它。另外，cookie中的数据时可以被客户端看见的。所以如果你需要对其中的数据进行保密，使用express-session将是一个更好的选择。
不要使用默认的session cookie名这点和禁用X-Powered-By头是类似的。潜在的攻击者可以通过它们进行针对性的攻击。
所以请使用比较普遍的cookie名；如：
var session = require("express-session");
app.set("trust proxy", 1) // trust first proxy
app.use( session({
secret : "s3Cur3",
name : "sessionId",
})
);
配置cookie的安全选项
通过配置以下的cookie选项来加强安全性：
secure – 确保浏览器使用HTTPS发送cookie。
httpOnly – 确保cookie仅通过HTTP(S)被发送，而不是客户端的JavaScript。用来帮助抵御跨站脚本攻击。
domain – 指定cookie的域。使用它来与将要发送cookie的URL作比较。只有比较结果通过，才会继续检查下面的path属性。
path – 指定cookie的路径。使用它来比较请求的路径。如果比较结果通过，才会发送cookie。
expires – 为持久化的cookie设置过期时间。
以下是一个使用cookie-session中间件的例子：
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
}
})
);
确保你的依赖库都是安全的
使用npm来管理你应用的依赖是强大而方便的。但是你的依赖库如果有安全隐患，这也会影响到你的应用。你的应用只会和其最虚弱的那部分一样的健壮。
幸运的是，有两个工具可以帮助你检查第三方库的安全性：nsp和requireSafe。这两个工具大致上干了相同的事情，所以选其一使用便好。
nsp是一个用来检查你应用的依赖库与它的Node Security Project数据库中的存储的漏洞相对比的命令行工具，你可以通过以下方式安装它：
$ npm i nsp -g
然后使用以下命令来进行检查你应用的npm-shrinkwrap.json和package.json：
$ cd your-app $ nap check
使用requireSafe的过程也是类似的：
$ npm install -g requiresafe $ cd your-app $ require safe check其他值得考虑的事
以下是一些从Node.js安全清单中提出安全建议。详细的建议请自行参阅它：
对应用实现一个访问频率限制机制来抵御暴力破解。你可以使用如express-limiter这样的中间件。
使用csurf中间件来抵挡跨站请求伪造（CSRF）。
总是检查和过滤用户的输入，来防止XSS和命令注入。
通过使用参数化的查询（parameterized queries）或预处理语句（prepared statements），来抵挡SQL注入攻击。
使用开源的sqlmap工具来侦测你的应用中可能被SQL注入的地方。
使用namp和sslyze来测试你的SSL配置。
使用safe-regex来确保你的正则表达式的健壮性。
避免其他已知的漏洞除了Node Security Project代替你检查出的Express或其他模块的漏洞外。Express应用也是一个web应用，所以你也要关注其他相关的已知的web漏洞，并且避免它们。
最后原文链接：https://strongloop.com/strongblog/best-practices-for-express-in-production-part-one-security/
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/86191.html
摘要：前言这将是一个分为两部分，内容是关于在生产环境下，跑应用的最佳实践。第一部分会关注安全性，第二部分则会关注性能和可靠性。关于第一部分，请参阅在生产环境下的最佳实践安全性。 前言 这将是一个分为两部分，内容是关于在生产环境下，跑Express应用的最佳实践。第一部分会关注安全性，第二部分则会关注性能和可靠性。当你读这篇文章时，会假设你已经对Node.js和web开发有所了解，并且对生产环...
摘要：防止受到跨站脚本攻击以及其他跨站注入攻击。管理对于的安全使用，其重要性是不言而喻的。设置这个属性将禁止脚本获取到这个，这可以用来帮助防止跨站脚本攻击。这个查询可能会变成最简单的预防方法则是使用参数化查询或预处理语句。 前言 安全性，总是一个不可忽视的问题。许多人都承认这点，但是却很少有人真的认真地对待它。所以我们列出了这个清单，让你在将你的应用部署到生产环境来给千万用户使用之前，做一个...
摘要：为应用增加新的特性和处理新的情况可能都会改变文件的结构。写一个模板的最佳实践是，不要在模板中处理数据。在上面这四个文件夹中，主要的测试代码将是单元测试，这意味着你需要将被测试的代码与应用分离开来。 前言 Node和Express并不严格要求它的应用的文件结构。你可以以任意的结构来组织你的web应用。这对于小应用来说，通常是不错的，十分易于学习和实验。 但是，当你的应用在体积和复杂性上都...
摘要：接下来我们将逐步的减少这个镜像的体积。优化生产环境镜像使用镜像大幅减小镜像体积的最简单和最快的方法是选择一个小得多的基本镜像。使用多阶段构建可以充分利用镜像的缓存，大大减少最终部署到生产环境的时间。 关注作者github每日一道面试题详解 你讨厌部署你的应用程序花费很长时间吗? 对于单个容器来说，超过gb并不是最佳实践。每次部署新版本时都要处理数十亿字节，这对我们来说并不太合适。 本文...
摘要：本文适合的读者现在在手淘，京东，今日头条，美柚等过亿用户的手机中的，都常见网页，他们有更新快，灵活，便于分享和传播的特性。这里有他们中的几个的例子手淘，美柚。 本文适合的读者???? 现在在手淘，京东，今日头条，美柚等过亿用户的手机app中的，都常见h5网页，他们有更新快，灵活，便于分享和传播的特性。这里有他们中的几个h5的例子：（手淘，美柚）。这些app中都嵌者数以百计，千计的...
阅读 988·2023-04-26 02:38
阅读 727·2023-04-25 20:13
阅读 3441·2021-11-19 11:31
阅读 2202·2019-08-30 15:55
阅读 2611·2019-08-30 14:11
阅读 3035·2019-08-30 13:45
阅读 1242·2019-08-29 18:41
阅读 1021·2019-08-29 16:18
