下面是您在开发和测试REST API时的安全准则列表，其中包括正确的授权、输入验证和输出编码。

在开发REST API时，必须从一开始就关注安全方面。在本文中，我将解释开发和测试REST API时的前5个安全指南。

REST是通过URL路径元素表达系统中特定实体的手段。REST不是一个架构，而是一种在Web上构建服务的架构风格。 REST允许通过简单的URL（而不是复杂的请求主体或POST参数）与基于web的系统交互。

1/5  - 授权

（1） 保护HTTP方法

RESTful API通常使用GET（读取），POST（创建），PUT（替换/更新）和DELETE（删除记录）。

对于每个资源并非都要提供所有这些操作。 必须确保传入的HTTP请求对于会话令牌/API密钥和相关资源的访问，操作和记录都是有效的。

例如，如果您有一个RESTful API的库，不允许匿名用户删除书目录，但他们可以读取书目录。 另一方面，对于图书馆员，这两个都是有效的。

（2） 白名单允许的方法

对于某个URL，有多种方法对应实体上的不同操作。

例如，GET请求可能是对应读取实体，而PUT将更新现有实体，POST将创建新实体，DELETE将删除现有实体。

对于服务来说，正确限制允许的动词非常重要，这样只有允许的动词可以工作，而其他所有动词都会返回正确的响应代码（例如，403 Forbidden）

（3） 保护特权操作和敏感资源集合

并非每个用户都有权访问每个Web服务。 这是至关重要的，因为您不希望Web服务的管理被滥用：

https://example.com/admin/exportAllData

这个URL是一个Web服务管理资源，其会话令牌或API密钥应作为cookie或内容参数发送，以防止未经授权的使用。

 

（4） 防止跨站点请求伪造

对于RESTful Web服务公开的资源，重要的是确保任何PUT，POST和DELETE请求都受到防止跨站点请求伪造的保护。 通常，使用基于令牌的方法。

如果您的应用程序中存在任何XSS，即使使用随机令牌也很容易实现CSRF，因此请确保您了解如何防止XSS。

（5） 不安全的直接对象引用

这似乎很明显，但如果你有一个银行帐户REST Web服务，你必须确保有足够的主键和外键检查：

在这种情况下，可以将钱从任何账户转移到其他账户，这显然是荒谬的。即使是随机令牌也不会使其安全。

https://example.com/invoice/2362365

在这种情况下，可以获得所有发票的副本。

这实质上是一种数据上下文访问控制实施需求。URL或甚至POST表单都不应包含提供自动验证的访问控制“密钥”或类似内容。每个请求都需要在服务器端完成数据上下文检查。

2/5 - 输入验证

您对输入验证所了解的所有内容都适用于RESTful Web服务，但增加了10％，因为自动化工具可以在高速下轻松地将您的界面自动化测试几个小时。所以：

协助用户>拒绝输入>清理（过滤）>无输入验证

帮助用户将高质量的数据输入到您的Web服务中，例如确保邮政编码对提供的地址有意义，或日期有意义。 如果不是，拒绝该输入。

现实情况是，任何人都可以调用您的Web服务，所以假设每秒执行上百次失败的输入验证的人是没有好处的

考虑将API限制为每小时或每天一定数量的请求，以防止滥用。

（1）网址验证

Web应用程序/ Web服务使用来自HTTP请求（有时是文件）的输入来确定如何响应。

攻击者可以篡改HTTP请求的任何部分，包括URL，查询字符串，标题，cookie，表单字段和隐藏字段，以试图绕过站点的安全机制。

常见输入篡改攻击的常见名称包括强制浏览，命令插入，跨站点脚本，缓冲区溢出，格式字符串攻击，SQL注入，cookie中毒和隐藏字段操作。

（2）安全解析

使用安全解析器来解析传入的消息。如果您使用的是XML，请确保使用不易受XXE和类似攻击的解析器。

（3）强类型

如果唯一允许的值为真或假，或者数字或少量可接受值之一，则很难执行大多数攻击。尽可能快地输入传入数据。

（4）验证传入的内容类型

在POSTing或PUTting新数据时，客户端将指定传入数据的Content-Type（例如application / xml或application / json）。

服务器永远不应该假设Content-Type， 它应该始终检查Content-Type标头和内容是否是同一类型。缺少Content-Type标头或意外的Content-Type标头应导致服务器拒绝具有406 Not Acceptable响应的内容。

（5）验证响应类型

REST服务通常允许多种响应类型（例如，应用程序/ XML或应用程序/ JSON，并且客户端通过请求中的Accept标头指定响应类型的首选顺序。

不要简单地将Accept头复制到响应的Content-type头。 如果Accept报头没有包含允许的类型中任何一个，则需要拒绝请求（理想情况下使用406 Not Acceptable响应）。

由于典型响应类型有许多MIME类型，因此请务必为客户端记录应使用哪种MIME类型。

（6）XML输入验证

基于XML的服务，必须通过使用安全的XML解析来确保它们免受常见的基于XML的攻击。

这通常意味着防止XML外部实体攻击，XML签名包装等。

3/5 - 输出编码

（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/5 - 密码学

（1）传输中的数据

除非公共信息是完全只读的，否则应强制使用TLS，特别是在执行凭据，更新，删除和任何值事务的情况下。在现代硬件上，TLS的开销可以忽略不计，延迟较小，而不是最终用户的安全补偿。

考虑使用相互认证的客户端证书为高权限Web服务提供额外保护。

（2）消息完整性

除了HTTPS / TLS之外，JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且独立的方式，用于在各方之间作为JSON对象安全地传输信息。

JWT不仅可以用于确保消息完整性，而且还可以用于消息发送者/接收者的认证。

JWT包括消息体的数字签名散列值，以确保传输过程中的消息完整性。

5/5 - HTTP状态代码

HTTP定义状态代码。设计REST API时，不要只使用200表示成功，或使用404表示错误。

以下是针对每个REST API状态返回代码考虑的一些准则。正确的错误处理可能有助于验证传入的请求，并更好地识别潜在的安全风险。

• 200 OK - 响应成功的REST API操作。HTTP方法可以是GET，POST，PUT，PATCH或DELETE。

• 400错误请求 - 请求格式错误，例如邮件正文格式错误。

• 401 Unauthorized - 提供的身份验证ID /密码错误或无。

• 403 Forbidden - 在身份验证成功但已通过身份验证的用户没有权限请求资源时使用。

• 404 Not Found - 请求不存在的资源时。

• 405不允许的方法 -意外的HTTP方法的错误检查。例如，RestAPI期望HTTP GET，但使用HTTP PUT。

• 429请求太多 - 当检测到DOS攻击或请求因速率限制而被拒绝时，将使用该错误

（1）401 vs 403

401“未经授权”实际上意味着未经身份验证，“您需要有效的凭据才能回复此请求”。

403“Forbidden”真的意味着未经授权，“我理解你的凭据，但很抱歉，你不被允许！”

在这篇文章中，我介绍了有关如何解决这些问题的前5个RESTful API安全问题和指南。遵循这些准则将产生更安全和高质量的REST API服务以及更多开发人员友好的REST API。

某些方法（例如，HEAD，GET，OPTIONS和TRACE）被定义为安全，这意味着它们仅用于信息检索，不应更改服务器的状态。

在设计和构建REST API时，您必须注意安全方面。

长按二维码 ▲

订阅「架构师小秘圈」公众号

如有启发，帮我点个在看，谢谢↓