在设计REST API或服务时，是否存在处理安全性(身份验证，授权，身份管理)的最佳实践？ 在构建SOAP API时，您可以使用WS-Security作为指导，有关该主题的文献很多。我发现了有关保护REST端点的更少信息。 尽管我了解REST故意没有类似于WS- *的规范，但我希望最佳实践或推荐模式已经出现。 任何有关文件的讨论或链接将非常感激。 如果它很重要，我们将使用WCF和POX/JSON序列化消息来构建使用.NET Framework v3.5构建的REST API/Services。
Github上有一个很棒的清单： 的验证
- 请勿使用
Basic Auth使用标准认证(例如JWT，OAuth)。 - 不要在认证，代币生成，密码存储中重新发明轮子。使用标准。
- 在登录中使用
Max Retry和jail功能。 - 在所有敏感数据上使用加密。
- JWT(JSON Web令牌)
- 使用一个随机的复杂键(JWT秘密)来让暴力令牌变得非常困难。
- 不要从有效负载中提取算法。在后端强制执行算法(HS256或RS256)。
- 尽可能缩短令牌到期时间(
TTL，RTTL)。 - 不要在
JWT有效载荷中存储敏感数据，它可以被轻松解码。 - 的的OAuth
- 始终验证
redirect_uri服务器端是否只允许列入白名单的网址。 - 总是尝试交换代码而不是代币(不允许
response_type=token)。 - 使用状态参数和随机散列来防止
OAuth身份验证过程中的CSRF。 - 定义默认范围，并为每个应用程序验证范围参数。
- 使用
- 限制请求(Throttling)以避免DDoS /强力攻击。
- 在服务器端使用HTTPS以避免MITM(中间人攻击)
- 使用带SSL的
HSTS标头来避免SSL Strip攻击。 - 的输入
- 根据操作使用适当的HTTP方法：
GET(读取)，POST(创建)，PUT/PATCH(替换/更新)和DELETE(删除记录)，如果请求的方法不是，则使用405 Method Not Allowed回应适合请求的资源。 - 根据请求验证内容类型
Accept标题(内容协商)以仅允许您支持的格式(例如application/xml，application/json等)，并在406 Not Acceptable响应中回应(如果不匹配)。 - 按照您接受的方式验证发布数据的
content-type(例如，application/x-www-form-urlencoded，multipart/form-data，application/json等)。 - 验证用户输入以避免常见漏洞(例如XSS，SQL注入，远程代码执行等)。
- 请勿在网址中使用任何敏感数据(凭据，密码，安全令牌或API密钥)，但请使用标准的
Authorization标头。 - 使用API网关服务启用缓存，
Rate Limit策略(例如配额，尖峰捕捉，并发速率限制)以及动态部署API资源。 - 的处理
- 检查所有端点是否在身份验证后受到保护，以避免身份验证过程中断。
- 应该避免用户自己的资源ID。使用/ me/orders而不是/ user/654321/orders。
- 不要自动增加ID。改为使用UUID。
- 如果您正在解析XML文件，请确保未启用实体解析以避免XXE(XML外部实体攻击)。
- 如果您正在解析XML文件，请确保实体展开未启用，以通过指数实体展开攻击来避免十亿笑/ XML炸弹。
- 使用CDN进行文件上传。
- 如果您处理大量数据，请使用工作人员和队列尽可能在后台进行处理，并快速返回响应以避免HTTP阻止。
- 不要忘记关闭 DEBUG 模式。
- 的输出
- 发送
X-Content-Type-Options: nosniff标头。 - 发送
X-Frame-Options: deny标头。 - 发送
Content-Security-Policy: default-src'none'标头。 - 移除指纹标头 -
X-Powered-By，Server，X-AspNet-Version等。 - 如果您返回
application/json，那么您的响应内容类型为application/json。 - 强制
content-type作为回应。 - 不要传回密码，密码，安全令牌等敏感数据。
- 根据完成的操作返回正确的状态码。 (例如
200 OK，400 Bad Request，401 Unauthorized，405 Method Not Allowed等)。
