本文目录一览：
nodejs安全吗
安全是不容忽视的，每个开发者都知道它非常重要，真正严肃对待它的却没有几人。我们 RisingStack 希望你能认真对待这一问题——这就是我们整理这份清单来帮助你的原因，你的应用在被成千上万用户使用前必须要做安全检查。
这份清单大部分内容是通用的，不仅适用于Node.js，同样适用于其他语言和框架，只是一些明确给出了在Node.js中使用的 *** 。同时推荐你去阅读我们的引导文章 Node.js security，如果你刚开始使用Node.js，推荐你看这篇文章 first chapter of Node Hero。
配置管理
HTTP 安全头部
有些关于安全的HTTP头部是你的网站必须要有的：
Strict-Transport-Security 强制将HTTP请求替换为HTTPS请求
X-Frame-Options 防止点击劫持
X-XSS-Protection 开启跨站脚本攻击（XSS）的过滤，大多数现代浏览器支持这个设置
X-Content-Type-Options 禁用浏览器对响应内容MIME类型的嗅探，严格使用响应的Content-Type的值
Content-Security-Policy 能有效防止多种攻击，包括跨站脚本和跨站注入
Node.js开发者可以使用Helmet模块置这些头部，代码如下：
var express = require('express');
var helmet = require('helmet');
var app = express();
app.use(helmet());
Koa和Think *** 框架中可以使用koa-helmet来设置这些头部，当然有关安全的头部不止这些，更多请看Helmet和MDN HTTP Headers。
在大多数架构里这些头部可以设置在web服务器的配置中（Apache、Nginx），不需要对应用代码进行改动。在Nginx中的配置：
# nginx.conf
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header Content-Security-Policy "default-src 'self'";
有一个完整的Nginx配置文件，帅气的传送门在此。
如果你想快速检查你的网站是否有了所有的必须头部，请使用这个在线检查器。
客户端的敏感数据
当发布前端应用时，确保你的代码里永远不会包含API密码和证书，因为它可以被任何人看到。
没有自动化的 *** 去检查你在代码里写了敏感数据，但是有两个可以降低向客户端暴露敏感数据风险的 *** ：
使用 pull requests 提交代码
定期 code review
如何解决繁琐的WEB前端的XSS问题
后台做一层过滤，前台文本编辑器可以自己做一层标签过滤，不允许一些符号的输入就行了
xss攻击前端能做的有限
因为好多都是url转码来通过参数找漏洞，所以后台也要做一层过滤（例如nodejs的sql库就只允许单行sql，防止通过xss做注入）java之类的有现成多xss过滤器
剩下的就做ip黑名单吧，防止多次攻击
求大神讲讲web安全，nodejs怎么防止跨域攻击和sql注入
是CSRF(Cross-site request forgery) 不是你写的那个!
跨域不用担心.主流浏览器都会帮你做防御的. 问题不大,主要是你自己别给其他域的权限即可.非必要的话,以最小权限原则.
xss主要就是过滤输入输出.如果业务很多,还是找人审计代码吧.或者用比较成熟的模块.CSRF的话,1,验证来源 2加随机token之类的.
sqli主要还是过滤输入的地方.过滤/转义关键字比如select,and,or等等(有专门的防注入模块).觉得怕麻烦的话.用那些云主机的防御功能.再加个cdn基本就没事了.(对于一般的反射型跨站也适用)
这个xss有过滤方案么
方案一：
避免XSS的 *** 之一主要是将用户所提供的内容输入输出进行过滤，许多语言都有提供对HTML的过滤：
可以利用下面这些函数对出现xss漏洞的参数进行过滤：
PHP的htmlentities()或是htmlspecialchars()。
Python 的 cgi.escape()。
ASP 的 ServerEncode()。
ASP.NET 的 ServerEncode() 或功能更强的 Microsoft Anti-Cross Site Scripting Library
Java 的 xssprotect(Open Source Library)。
Node.js 的 node-validator。
方案二：使用开源的漏洞修复插件。（ 需要站长懂得编程并且能够修改服务器代码 ）
nodejs怎么设置cookie
var http = require('http');
http.createServer(function (req, res) {
// 获得客户端的Cookie
var Cookies = {};
req.headers.cookie req.headers.cookie.split(';').forEach(function( Cookie ) {
var parts = Cookie.split('=');
Cookies[ parts[ 0 ].trim() ] = ( parts[ 1 ] || '' ).trim();
});
console.log(Cookies)
// 向客户端设置一个Cookie
res.writeHead(200, {
'Set-Cookie': 'myCookie=test',
'Content-Type': 'text/plain'
});
res.end('Hello World\n');
}).listen(8000);
console.log('Server running at ');
如果去掉其中几句，就是官方给出的例子，除了表明返回一个页面多简单外，一点用也没有。
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8000);
console.log('Server running at ');
我们通过http.createServer的回调来处理所有请求与响应，因此什么有用的东西都在它们上面。Cookie位于req对象的headers对象上，为一个字符串，通常为了方便我们将它们转换成一个对象。
写入一个Cookie其实就是在首部设置一个键值对，上面是简单方式，它实际上可以这样：
res.writeHead(200, {
'Set-Cookie': ["aaa=bbb","ccc=ddd","eee=fff"],
'Content-Type': 'text/plain'
});
但真正使用时，我们的Cookie并非这样简单的的格式：
Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly]
console.log('Server running at ');
HttpOnly 属性： 这是微软对Cookie做的扩展。如果在Cookie中设置了"HttpOnly"属性，那么通过程序( *** 脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。
var http = require('http');
http.createServer(function (req, res) {
// 获得客户端的Cookie
var Cookies = {};
req.headers.cookie req.headers.cookie.split(';').forEach(function( Cookie ) {
var parts = Cookie.split('=');
Cookies[ parts[ 0 ].trim() ] = ( parts[ 1 ] || '' ).trim();
});
console.log(Cookies)
// 向客户端设置一个Cookie
res.writeHead(200, {
'Set-Cookie': 'SSID=Ap4GTEq; Expires=Wed, 13-Jan-2021 22:23:01 GMT;HttpOnly ',
'Content-Type': 'text/html'
});
res.end('Hello World\nscriptconsole.log(document.Cookie)/script');
}).listen(8000);
console.log('Server running at ');
然后多刷几次页面，我们发现我们还能在控制台看到SSID=Ap4GTEq这个属性，但在前端我们看不到它（当然在firebug中能看到）。
Secure属性： 当设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该信息，所以不会被窃取到Cookie 的具体内容。同上，在客户端我们也无法在document.Cookie找到被设置了Secure=true的Cookie键值对。Secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取Cookie后进行攻击。我们可以把Secure=true看成比HttpOnly更严格的访问控制。
path属性： 指定可访问Cookie的目录。例如："userId=320; path=/shop";就表示当前Cookie仅能在shop目录下使用。
domain属性： 指定可访问Cookie的主机名.主机名是指同一个域下的不同主机，例如：和gmail.google.com就是两个不同的主机名。默认情况下，一个主机中创建的Cookie在另一个主机下是不能被访问的， 但可以通过domain参数来实现对其的控制，其语法格式为："name=value; domain=CookieDomain";以google为例，要实现跨主机访问，可以写为： "name=value;domain=.google.com";这样，所有google.com下的主机都可以访问该Cookie。
Expires属性：指定过期时间，格式为"name=value;; expires=GMT_String"; 其中GMT_String是以GMT格式表示的时间字符串，超过这个时间，Cookie将消失，不可访问。例如：如果要将Cookie设置为10天后过期，可以这样实现：