以下是当你在设计, 测试以及发布你的 API 的时候所需要核对的重要安全措施.

身份认证

• 不要使用 Basic Auth 使用标准的认证协议 (如 JWT, OAuth).
• 不要再造 Authentication, token generating, password storing 这些轮子, 使用标准的.
• 在登录中使用 Max Retry 和自动封禁功能.
• 加密所有的敏感数据.

JWT (JSON Web Token)

• 使用随机复杂的密钥 (JWT Secret) 以增加暴力破解的难度.
• 不要在请求体中直接提取数据, 要对数据进行加密 (HS256 或 RS256).
• 使 token 的过期时间尽量的短 (TTL, RTTL).
• 不要在 JWT 的请求体中存放敏感数据, 它是可破解的.

OAuth 授权或认证协议

• 始终在后台验证 redirect_uri, 只允许白名单的 URL.
• 每次交换令牌的时候不要加 token (不允许 response_type=token).
• 使用 state 参数并填充随机的哈希数来防止跨站请求伪造(CSRF).
• 对不同的应用分别定义默认的作用域和各自有效的作用域参数.

访问

• 限制流量来防止 DDoS 攻击和暴力攻击.
• 在服务端使用 HTTPS 协议来防止 MITM 攻击.
• 使用 HSTS 协议防止 SSLStrip 攻击.

输入

• 使用与操作相符的 HTTP 操作函数, GET (读取), POST (创建), PUT (替换/更新) 以及 DELETE (删除记录), 如果请求的方法不适用于请求的资源则返回 405 Method Not Allowed.
• 在请求头中的 content-type 字段使用内容验证来只允许支持的格式 (如 application/xml, application/json 等等) 并在不满足条件的时候返回 406 Not Acceptable.
• 验证 content-type 的发布数据和你收到的一样 (如 application/x-www-form-urlencoded, multipart/form-data, application/json 等等).
• 验证用户输入来避免一些普通的易受攻击缺陷 (如 XSS, SQL-注入, 远程代码执行 等等).
• 不要在 URL 中使用任何敏感的数据 (credentials, Passwords, security tokens, or API keys), 而是使用标准的认证请求头.
• 使用一个 API Gateway 服务来启用缓存、访问速率限制 (如 Quota, Spike Arrest, Concurrent Rate Limit) 以及动态地部署 APIs resources.

处理

• 检查是否所有的终端都在身份认证之后, 以避免被破坏了的认证体系.
• 避免使用特有的资源 id. 使用 /me/orders 替代 /user/654321/orders
• 使用 UUID 代替自增长的 id.
• 如果需要解析 XML 文件, 确保实体解析(entity parsing)是关闭的以避免 XXE 攻击.
• 如果需要解析 XML 文件, 确保实体扩展(entity expansion)是关闭的以避免通过指数实体扩展攻击实现的 Billion Laughs/XML bomb.
• 在文件上传中使用 CDN.
• 如果需要处理大量的数据, 使用 Workers 和 Queues 来快速响应, 从而避免 HTTP 阻塞.
• 不要忘了把 DEBUG 模式关掉.

输出

• 发送 X-Content-Type-Options: nosniff 头.
• 发送 X-Frame-Options: deny 头.
• 发送 Content-Security-Policy: default-src 'none' 头.
• 删除指纹头 - X-Powered-By, Server, X-AspNet-Version 等等.
• 在响应中强制使用 content-type, 如果你的类型是 application/json 那么你的 content-type 就是 application/json.
• 不要返回敏感的数据, 如 credentials, Passwords, security tokens.
• 在操作结束时返回恰当的状态码. (如 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed 等等).

持续集成和持续部署

• 使用单元测试和集成测试来审计你的设计和实现.
• 引入代码审查流程, 不要自行批准更改.
• 在推送到生产环境之前确保服务的所有组件都用杀毒软件静态地扫描过, 包括第三方库和其它依赖.
• 为部署设计一个回滚方案.

原文地址
网上都说操作真实dom怎么怎么慢，但是下面这个链接案例中原生的方式却是最快的
http://chrisharrington.github.io/demos/performance/

我在本地也写了个例子循环2000个随机数组，点击按钮重新生成随机数组渲染页面，也是自己用的js 操作dom 比用react 和angular 都要快，这个是怎么回事。测试方式不对，页面元素太少了，还是哪里问题，请帮忙解答下，谢谢。

鉴于有人表示没有看懂。 下面是结论:

• 题主测试结果反常是因为测试用例构造有问题。
• React.js 相对于直接操作原生DOM有很大的性能优势， 背后的技术支撑是基于virtual DOM的batching 和diff.
• React.js 的使用的virtual DOM 在Javascript Engine中也有执行效率的优势。

众所周知，前端近几年闹了一场革命。前端在编程领域也掀起了学习潮。至少在中国，从2013年下半年至今，在搜索指数上，有着爆炸式的增长。可以看下数据：百度指数，Google指数。

更换为next主题

进入hexo站点文件夹

1

cd your-hexo-site

clone Next代码并存放到 themes/next 目录下（用目前比较火的next主题为例）

1

git clone https://github.com/iissnan/hexo-theme-next themes/next

在站点 _config.yml 中修改:

1

theme: next

配置环境

安装Node（必须）
作用：用来生成静态页面的
到Node.js官网下载相应平台的最新版本，一路安装即可。

安装Git（必须）
作用：把本地的hexo内容提交到github上去.
安装Xcode就自带有Git，我就不多说了,windows就去官网下载git。

申请GitHub（必须）
作用：是用来做博客的远程创库、域名、服务器之类的，怎么与本地hexo建立连接等下讲。
github账号我也不再啰嗦了,没有的话直接申请就行了，跟一般的注册账号差不多，SSH Keys，看你自己了，可以不配制，不配置的话以后每次对自己的博客有改动提交的时候就要手动输入账号密码，配置了就不需要了，怎么配置我就不多说了，网上有很多教程。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment