前言
4.1 基于表单的权限验证
4.2 基础鉴权
4.3 一次是不够的、二次、三次（验证）….
4.4 为什么使用不安全的文本消息? HOTP & TOTP 介绍
4.5 处理密码重置 权限验证: 我能做什么？
5.1 基于Token的权限验证
5.2 OAuth 和 OAuth2
5.3 JWT（JSON Web Token） 数据校验和过滤: 绝不信任用户输入
6.1 校验和过滤用户输入
6.2 过滤输出
6.3 跨站脚本攻击（XSS）
6.4 注入攻击
6.5 用户上传
6.6 用户篡改输入 纯文本 != 编码 != 加密 != 哈希
7.1 通用编码模式
7.2 加密
7.3 哈希和单向函数（功能）
7.4 哈希速度对照表 密码: dadada、123456、cute@123
8.1 密码策略
8.2 密码存储
8.3 没有密码的生活 公钥加密 会话: 请记住我
10.1 哪里存储状态？
10.2 使会话失效
10.3 Cookie怪物和你 加固安全, 一次只有一个头信息
11.1 安全的web header
11.2 第三方代码的数据集成检测
11.3 证书绑定 配置错误
12.1 云上准备: 端口、Shodan、AWS
12.2 亲，你开了debug模式
12.3 日志（或者没有日志）
12.4 监控
12.5 最低优先级原理
12.6 （请求）频率限制 和 Captchas
12.7 把项目的密钥和密码保存在文件上
12.8 DNS: 关于子域名和被遗忘的宠物计划
12.9 打补丁和更新 攻击: 当坏人来临
13.1 点击劫持
13.2 跨站请求伪造
13.3 拒绝服务
13.4 服务端请求伪造 互联网公司漏洞统计 重造轮子，但做出来是方的
15.1 python的安全库和包
15.2 NodeJS的安全库和包
15.3 学习资料 掌握良好的安全习惯 安全性 vs 可用性 回到第1条: 安全Checklist解释 我们是谁?
本文来自 https://github.com/FallibleInc/security-guide-for-developers ，这是一篇web开发人员的安全须知（指南），是由 FallibleInc 公司提炼出来的，发布在github上面，我自己把的相关文档翻译成简体中文，他们也对我比较信任，给我开了这个repo的写权限，如果你发现有翻译得不正确的地方，欢迎提交PR， 我这边有权限可以合并。
目标读者安全问题主要由以下两类原因导致：
那些刚入门的无法区分MD5和bcrypt作用的开发者 那些知道这件事但忘记/忽略了的开发者我们的详细说明应该可以帮到第1类开发者，而我们希望的我们的checklist可以帮到第2类的开发者构建更多安全的系统。这绝不是一个综合性的指南，仅仅是覆盖了大多数我们过去发现的比较常见的问题。
目录 安全Checklist 什么东西会出问题? 安全地传输数据: HTTPS 详解 权限验证: 我是谁？4.1 基于表单的权限验证
4.2 基础鉴权
4.3 一次是不够的、二次、三次（验证）….
4.4 为什么使用不安全的文本消息? HOTP & TOTP 介绍
4.5 处理密码重置 权限验证: 我能做什么？
5.1 基于Token的权限验证
5.2 OAuth 和 OAuth2
5.3 JWT（JSON Web Token） 数据校验和过滤: 绝不信任用户输入
6.1 校验和过滤用户输入
6.2 过滤输出
6.3 跨站脚本攻击（XSS）
6.4 注入攻击
6.5 用户上传
6.6 用户篡改输入 纯文本 != 编码 != 加密 != 哈希
7.1 通用编码模式
7.2 加密
7.3 哈希和单向函数（功能）
7.4 哈希速度对照表 密码: dadada、123456、cute@123
8.1 密码策略
8.2 密码存储
8.3 没有密码的生活 公钥加密 会话: 请记住我
10.1 哪里存储状态？
10.2 使会话失效
10.3 Cookie怪物和你 加固安全, 一次只有一个头信息
11.1 安全的web header
11.2 第三方代码的数据集成检测
11.3 证书绑定 配置错误
12.1 云上准备: 端口、Shodan、AWS
12.2 亲，你开了debug模式
12.3 日志（或者没有日志）
12.4 监控
12.5 最低优先级原理
12.6 （请求）频率限制 和 Captchas
12.7 把项目的密钥和密码保存在文件上
12.8 DNS: 关于子域名和被遗忘的宠物计划
12.9 打补丁和更新 攻击: 当坏人来临
13.1 点击劫持
13.2 跨站请求伪造
13.3 拒绝服务
13.4 服务端请求伪造 互联网公司漏洞统计 重造轮子，但做出来是方的
15.1 python的安全库和包
15.2 NodeJS的安全库和包
15.3 学习资料 掌握良好的安全习惯 安全性 vs 可用性 回到第1条: 安全Checklist解释 我们是谁?
我们是全栈开发工程师，讨厌看到那些所谓为了做某件事情而hack，但写了一堆不安全的代码的开发者。在过去六个月，我们保护了超过1500w信用卡信息以及超过4500w用户的个人信息以及被盗，以及防止了大量的公司倒闭。最近，我们发现一个安全问题就能使一家比特币交易公司数据泄露从而倒闭。我们以及帮助了若干创业公司让他们的系统更安全，大多数是免费的，有时候甚至连『谢谢』都没收到：）
如果你不同意我们的观点或者找到bug，请开启一个issue或者提交一个PR给我们。另外，你也可以通过 hello@fallible.co 与我们交流。
安全checklist 权限系统 (注册/注册/二次验证/密码重置) 任何地方都使用HTTPS. 使用 Bcrypt 存储密码哈希 (没有使用盐的必要 Bcrypt 干的就是加密这个事情). 登出 之后销毁会话ID . 密码重置后销毁所有活跃的会话. OAuth2 验证必须包含 state 参数. 登陆成功之后不能直接重定向到开放的路径（需要校验，否则容易存在钓鱼攻击）. 当解析用户注册/登陆的输入时，过滤 javascript://、 data:// 以及其他 CRLF 字符. 使用 secure/httpOnly cookies. 移动端使用 OTP 验证时，当调用 generate OTP 或者 Resend OTP API时不能吧OTP（One Time Password）直接返回。（一般是通过发送手机验证短信，邮箱随机code等方式，而不是直接response） 限制单个用户 Login 、 Verify OTP 、 Resend OTP 、 generate OTP 等API的调用次数，使用Captcha等手段防止暴力破解. 检查邮件或短信里的重置密码的token，确保随机性（无法猜测） 给重置密码的token设置过期时间. 重置密码成功后，将重置使用的token失效. 用户数据和权限校验 诸如 我的购物车 、 我的浏览历史 之类的资源访问，必须检查当前登录的用户是否有这些资源的访问权限。 避免资源ID被连续遍历访问，使用 /me/orders 代替 /user/37153/orders 以防你忘了检查权限，导致数据泄露。 修改邮箱/手机号码 功能必须首先确认用户已经验证过邮箱/手机是他自己的。 任何上传功能应该过滤用户上传的文件名，另外，为了普适性的原因（而不是安全问题），上传的东西应该存放到例如S3之类的云存储上面，而不是存储在这几的服务器，防止代码执行。 个人头像上传 功能应该过滤所有的 EXIF 标签，即便没有这个需求. 用户ID或者其他的ID，应该使用 RFC compliant 的 UUID 而不是整数. 你可以从github找到你所用的语言的实现. JWT（JSON Web Token） 很棒.当你需要做一个单页应用/API的使用使用. 安卓和iOS APP 支付网关的 盐（salt） 不应该硬编码 来自第三方的 secret 和 auth token 不应该硬编码 在服务器之间调用的API不应该在app里面调用 在安卓系统下，要小心评估所有申请的 权限 在iOS系统下，使用系统的钥匙串来存储敏感信息（权限token，api key等等）。 不要 把这类信息存储在用户配置里面 强烈推荐 证书绑定（Certificate pinning） 安全头信息和配置 添加 CSP 头信息，减缓 XSS 和数据注入攻击. 这很重要. 添加 CSRF 头信息防止跨站请求调用（CSRF）攻击.同时 添加 SameSite 属性到cookie里面. 添加 HSTS 头信息防止SSL stripping攻击. 添加 你的域名到 HSTS 预加载列表 添加 X-Frame-Options 防止点击劫持. 添加 X-XSS-Protection 缓解XSS攻击. 更新 DNS记录，增加 SPF 记录防止垃圾邮件和钓鱼攻击. 如果你的Javascript 库存放在第三方的CDN上面，需要 添加 内部资源集成检查 。为了更加安全，添加 require-sri-for CSP-directive 就不会加载到没有SRI的资源。 使用随机的CSRF