安全不是事后的想法。它必须是任何开发项目和REST API的组成部分。有多种方法可以保护RESTful API，例如 基本身份验证（ ） ， OAuth （）等。但有一件事是确保RESTful API应该是无状态的 – 因此请求身份验证/授权不应该依赖于cookie或会话。相反，每个API请求都应附带一些排序身份验证凭据，必须在服务器上为每个请求验证。
REST安全设计原则
论文“信息的保护计算机系统”，由杰罗姆Saltzer和迈克尔·施罗德，提出8个的设计原则在计算机系统中保护信息，如下面的章节中描述：
googletag.cmd.push(function() { googletag.display(‘waldo-tag-4084’); });
- 最小权限： 实体应该只具有所需的权限集来执行授权的操作，而不再执行。可以根据需要添加权限，并在不再使用时撤消。
- 失败保护默认值： 用户对系统中任何资源的默认访问级别应被“拒绝”，除非他们已明确授予“许可”。
- 机制经济： 设计应尽可能简单。所有组件接口和它们之间的交互应该足够简单易懂。
- 完全中介： 系统应验证其所有资源的访问权限，以确保它们被允许且不应依赖缓存的权限矩阵。如果正在撤消对给定资源的访问级别，但未在权限矩阵中反映，则会违反安全性。
- 开放式设计： 该原则强调了以开放的方式构建系统的重要性 – 没有秘密的机密算法。
- 权限分离： 授予实体权限不应完全基于单一条件，基于资源类型的条件组合更好。
- 最不常见的机制： 它涉及在不同组件之间共享状态的风险。如果可以破坏共享状态，则可以破坏依赖于它的所有其他组件。
- 心理可接受性： 它指出安全机制不应使资源更难以访问，而不是安全机制不存在。简而言之，安全性不应该使用户体验变得更糟。
保护REST API的最佳实践
下面给出的点可以作为设计REST API安全机制的核对表。
把事情简单化
保护API /系统 – 它需要多么安全。每当你“不必要地”使解决方案变得更加复杂时，你也可能会留下一个漏洞。
始终使用HTTPS
通过始终使用 SSL ，可以将身份验证凭据简化为随机生成的访问令牌，该令牌在HTTP Basic Auth的用户名字段中提供。它使用起来相对简单，您可以免费获得许多安全功能。
如果使用 HTTP 2 （）来提高性能 – 您甚至可以通过 单个连接发送多个请求（ ） ，这样就可以避免以后的请求产生完整的TCP和SSL握手开销。
使用密码哈希
必须始终对密码进行哈希处理以保护系统（或将损坏降至最低），即使在某些黑客攻击中它受到损害。有许多这样的散列算法可以证明对密码安全性非常有效，例如MD5， SHA ，PBKDF2，bcrypt和scrypt算法。
永远不要公开URL的信息
用户名，密码，会话令牌和API密钥不应出现在URL中，因为这可以在Web服务器日志中捕获，这使它们很容易被利用。
{id}/someAction?apiKey=abcd123456789 //非常糟糕!!
以上URL公开API密钥所以，永远不要使用这种形式的安全性。
考虑一下OAuth
虽然 基本身份验证（ ） 对于大多数API都足够好，但如果正确实现，它也是安全的 – 但您也可能想要考虑OAuth。OAuth 2.0授权框架允许第三方应用程序通过编排资源所有者和HTTP服务之间的批准交互，或者通过允许第三方应用程序来代表资源所有者获得对HTTP服务的有限访问权限以自己的名义获取访问权限。
考虑在请求中添加时间戳
与其他请求参数一起，您可以在API请求中将请求时间戳添加为HTTP自定义标头。服务器会将当前时间戳与请求时间戳进行比较，并且只有在合理的时间范围内（可能是1-2分钟）才接受请求。
这将阻止那些试图在不更改此时间戳的情况下 强行执行（ ） 系统的人进行非常基本的 重播攻击 （）。
输入参数验证
在到达应用程序逻辑之前，在第一步验证请求参数。如果验证失败，请进行强有力的验证检查并立即拒绝请求。在API响应中，发送相关的错误消息和正确输入格式的示例以改善用户体验。
