当开发REST API时，从一开始就必须注意安全方面。
REST是通过URL路径元素表达系统中特定实体的手段。REST不是一个架构，而是一种在Web上构建服务的架构风格。 REST允许通过简单的URL（而不是复杂的请求主体或POST参数）与基于web的系统交互。
1 - 授权
（1）保护HTTP方法
RESTful API通常使用GET（读），POST（创建），PUT（替换/更新）和DELETE（删除记录）。
对于每个资源并非都要提供所有这些操作。 必须确保传入的HTTP方法对于会话令牌/API密钥和相关资源集合，操作和记录都是有效的。
例如，如果您有一个RESTful API的库，不允许匿名用户删除书目录条目，但他们可以获得书目录条目。 另一方面，对于图书馆员，这两个都是有效的。
请了解CORS，请启用网站的CORS。
（2）白名单允许的方法
对于某个URL，有多种方法对应实体上的不同操作。
例如，GET请求可能是对应读取实体，而PUT将更新现有实体，POST将创建一个新实体，DELETE将删除现有实体。
只允许需要的动词，其他动词将返回适当的响应代码 （ 例如，禁止一个403）。
（3）保护特权操作和敏感资源集合
并非每个用户都有权访问每个Web服务。 这是至关重要的，因为您不希望Web服务的管理被滥用：
https://example.com/admin/exportAllData
这个URL是一个Web服务管理资源，其会话令牌或API密钥应作为cookie或内容参数发送，以确保特权集合或操作得到正确保护，防止未经授权的使用。
（4）防止跨站点请求伪造
对于RESTful Web服务公开的资源，重要的是确保任何PUT，POST和DELETE请求都受到防止跨站点请求伪造的保护。 通常，使用基于令牌的方法。
CSRF很容易通过随机令牌防止XSS。
2 - 输入验证
帮助用户将高质量的数据输入到您的Web服务中，例如确保邮政编码对提供的地址有意义，或日期有意义。 如果不是，拒绝该输入。
现实情况是，任何人都可以调用您的Web服务，所以假设每秒执行上百次失败的输入验证的人是没有好处的。考虑将API限制为每小时或每天一定数量的请求，以防止滥用。
（1）网址验证
攻击者可以篡改HTTP请求的任何部分，包括url，查询字符串，标题，Cookie，表单字段和隐藏字段，以尝试绕过网站的安全机制。
常见的输入篡改攻击的常用名称包括：强制浏览，命令插入，跨站脚本，缓冲区溢出，格式字符串攻击，SQL注入，cookie中毒和隐藏字段操作。
（2）验证传入的内容类型
当POSTing或PUTting新数据时，，客户端将需要指定传入数据的Content-Type（例如application / xml或application / json）。
服务器不应该猜测Content-Type
它应该总是检查Content-Type头和内容是否是相同的类型。 缺少Content-Type头或意外Content-Type头应该导致服务器拒绝，发出406无法接受响应。
（3）验证响应类型
REST服务通常允许多种响应类型（例如application / xml或application / json，客户端通过请求中的Accept头指定响应类型的首选顺序）。
不要简单地将Accept头复制到响应的Content-type头。 如果Accept报头没有包含允许的类型中任何一个，则需要拒绝请求（理想情况下使用406 Not Acceptable响应）。
因为典型的响应类型有许多MIME类型，所以重要的是为客户端特别记录应该使用哪些MIME类型。
（4）XML输入验证
基于XML的服务必须确保通过使用安全的XML解析来保护它们免受常见的基于XML的攻击。
这通常意味着防范XML外部实体攻击，XML签名包装等。
见http://ws-attacks.org有关此类攻击的例子。
3 - 输出编码
（1）安全头部
为了确保指定资源的内容被浏览器正确解释，服务器应始终发送带有正确Content-Type的Content-Type头，并且Content-Type头最好包含一个字符集。
服务器还应发送X-Content-Type-Options：nosniff，以确保浏览器不会尝试检测不同于实际发送的内容类型的其它类型（会导致XSS）。
此外，客户端应该发送X-Frame-Options：deny来防止旧版本浏览器中的drag'n drop clickjacking攻击。
（2）JSON编码
JSON编码器的一个关键问题是阻止在浏览器中执行任意JavaScript远程代码...或者，如果您在服务器上使用node.js。 使用正确的JSON序列化程序来正确编码用户提供的数据，以防止在浏览器上执行用户提供的输入，这一点至关重要。
当在浏览器DOM中插入值时，强烈建议使用.value / .innerText / .textContent而不是使用.innerHTML来更新，因为这样可以防范简单的DOM XSS攻击。
（3）XML编码
XML绝不应该由字符串连接构建。 它应该始终使用XML序列化器构造。 这确保发送到浏览器的XML内容是可解析的，并且不包含XML注入。
4 - 加密
（1）传输中的数据
除非公共信息是完全只读的，否则应强制使用TLS，特别是在执行凭证更新、删除和任何事务操作时。 TLS的开销在现代硬件上是可以忽略的，具有微小的延迟增加，其对于最终用户的安全性得到更多的补偿。
考虑使用相互认证的客户端证书为高度特权的Web服务提供额外的保护。
（2）存储中的数据
在正确处理存储敏感或管制数据时，建议实现最佳实践。 有关详细信息，请参阅OWASP 2010年前10 - A7不安全加密存储。
（3）消息完整性
除了HTTPS / TLS，JSON网络令牌（JWT）是一个开放标准（ RFC 7519 ），它定义了一个JSON对象参与者之间安全地传送信息的紧凑且自成一体的方式。
JWT不仅可以用于确保消息完整性，而且还可以用于消息发送者/接收者的认证。
JWT包括消息体的数字签名哈希值，以确保在传输期间的消息完整性。 欲了解更多信息，您可以访问https://jwt.io/introduction/ 。
5 - HTTP状态代码
HTTP定义了状态码。 当设计REST API时，不要只使用200成功或404错误。
以下是每个REST API状态返回代码要考虑的一些指南。 正确的错误处理可以帮助验证传入的请求，并更好地识别潜在的安全风险。
200 OK -回应一个成功的REST API的行动。HTTP方法可以是GET，POST，PUT，PATCH或DELETE。
400错误请求 -请求格式错误，如消息正文格式错误。
401未授权 -错误或没有提供任何authencation ID /密码。
403禁止 -当身份验证成功，但身份验证的用户没有权限使用请求的资源。
404未找到 -当请求一个不存在的资源。
405不允许的方法 -意外的HTTP方法的错误检查。 例如，RestAPI期待HTTP GET，但使用HTTP PUT。
429太多的请求 -可能存在的DOS攻击检测或由于速率限制的请求被拒绝
（1）401和403
401“未授权”的真正含义未经身份验证的，“需要有效凭据才能作出回应。”
403“禁止”的真正含义未经授权，“我明白您的凭据，但很抱歉，你是不允许的！”
概要
在这篇文章中，介绍了5个RESTful API安全问题和如何解决这些问题的指南。遵循这些准则将导致更安全和高质量的REST API服务和更多的开发人员友好的REST API。
一些方法（例如，HEAD，GET，OPTIONS和TRACE）被定义为安全的，这意味着它们仅用于信息检索，并且不应该更改服务器的状态。在设计和构建REST API时，您必须注意安全方面。
来源：oschina
链接：https://my.oschina.net/alin520/blog/3229323