REST是一种非常流行的Web应用程序体系结构。 为了调用服务器上的函数，使用具有指定参数的普通HTTP请求（通常使用JSON或XML来构造参数），而REST体系结构没有严格的标准，这增加了灵活性（当然，也有些混乱）。
REST使您可以灵活地解决安全性问题，或者比许多缺点更根本不用解决问题。 在
OWASP的基础上，我们准备了一系列提示，以帮助您提高REST应用程序的安全性。
作为在极少数情况下（此处需要）的起点，我们使用python和Django。
规则0
Https
只需设置即可。 拜托 传输数据的保护并未损害任何人。 即使您认为目前没有什么可保护的，也并非总是如此，您仍然必须配置HTTPS。 因此，立即对其进行更好的配置，每个人都可以。
规则一
认证方式
似乎很明显的建议，但是，许多人倾向于忽略。 该应用程序应该始终具有身份验证，即使您现在认为仅在公司内部使用它，并且由哪个员工进行身份验证也没有区别。 而且，如果您在杂志上添加更多内容，那么调查事件和分析活动将变得无比简单。
作为访问令牌，目前认为使用
JWT （JSON Web令牌）是一种好习惯。 请勿使用值为{“ alg”：“ none”}的令牌进行完整性控制，令牌应始终包含签名或MAC！ 由于MAC的生成密钥和验证密钥相匹配（或可以很容易地相互计算），也就是说，如果服务器能够检查MAC值，则它也可以生成其值，因此签名是优选的。 签名不仅可以确认消息的完整性，还可以确认发送者的身份。
规则二
拒绝不使用的HTTP方法
将服务器配置为将您使用的那些方法（GET，POST，PUT等）列入白名单，并拒绝所有不适合此列表的方法。 您的服务器不太可能需要在生产时处理TRACE请求（此方法是XST攻击（跨站点跟踪）的一部分，该攻击由XSS攻击和TRACE或TRACK方法组成。例如，这种攻击可以窃取用户的Cookie，即使它们被标记为HttpOnly）。 外部可获得的有关基础架构的信息越少越好。
规则三
差异化访问
是否所有用户都需要所有方法，例如DELETE？ 如果您不希望某些用户能够执行某些操作，请在应用程序中配置访问控制。 例如，对于某些功能，普通用户只能访问GET方法，管理器可以使用GET和POST等。为此，值得在数据库中设置可以分配给用户的角色以方便访问控制。
结果，每个函数将具有一个近似于此类型的检查块：
if request.POST and user.is_manager: do_stuff()
规则四
考虑限制查询数量
如果您认为用户不应每秒向您发送十万个请求，则应限制此数目。 使用API密钥或任何其他方便您跟踪和限制在一定时间内来自一个用户的请求数量的机制。 例如，对于Django，django-ratelimit提供了此功能，您可以在其中设置各种参数作为限制的标识符，不一定是API密钥，而是IP地址。
规则五
确保验证/清理输入
永远不要相信传输的输入参数，总是进行验证/卫生：
- 如果可能（和可能的话），请设置输入和请求本身的长度/类型/格式限制。 拒绝所有超过您指定的长度或与类型/格式不匹配的请求/传输的数据。
- 处理字符串时，请始终转义所有特殊字符。
- 如果您使用该框架，则其中大多数都包含其自己的内置验证和卫生工具（较流行的工具-Django（python）和Yii2（php）），因此，研究其功能非常重要，如果您需要的某些方面没有涵盖在内-找到一个可以关闭此库的库，或者自己编写此类功能。
- 跟踪验证错误。 如果某些用户的请求始终无法通过验证-请考虑自动阻止此类用户。
- 确保您的输入解析器（或其当前版本）本身不受任何攻击。
规则六
不要提供不必要的更多信息
如果任何请求在应用程序中导致错误，或者由于某种原因而无法使用，请不要在响应中提供详细信息，并返回最抽象的错误消息。 默认情况下，某些服务器在发生错误后返回stacktrace，因此请确保重新配置此逻辑。
规则七
始终保留日志
让每个事件（身份验证，错误，请求等）都尽可能详细地记录下来。 逻辑上记录它们，以便在必要时更方便地搜索它们。 以防万一，在记录日志之前，请清理记录的数据。
规则八
正确指示Content-Type-这很重要！
为了使浏览器（或客户端）正确读取提供的数据，与提供的数据相对应的正确指定的Content-Type很重要。 对于浏览器，还应将标头设置为X-Content-Type-Options：nosniff，以防止浏览器尝试检测实际发送的Content-Type之外的其他Content-Type（一种针对XSS攻击的措施）。
规则9
验证内容类型
- 如果它们的Content-Type与它们的内容不同，则值得设置拒绝请求。 这将减少不正确的数据处理的风险，这可能导致服务器/客户端执行注入或代码执行。
- 拒绝您不支持其Content-Type或通常不存在此标头的请求也是值得的。 如果不是必须的，还避免直接回答哪个Content-Type函数接受/发布（这将有助于避免XXE攻击）。
- 在REST服务中，通常支持几种类型的响应（例如json和xml），并且客户端在请求时会在Accept标头中指示首选的响应类型。 避免将Accept标头的内容复制到响应的Content-Type中，作为设置此标头的一种机制。 还拒绝那些接受标头不直接包含至少一种支持的类型的请求。
规则十
不要忘记设置跨域资源共享（CORS）
CORS是描述使用跨域查询的标准。 如果您的应用程序不支持CORS，请禁用此类标头。 如果需要使用它，则访问策略应尽可能具体且严格。
规则11
不要在URL中扩展参数
所有关键数据（密码，密钥，令牌和登录名，最好也应该是）都应位于请求正文中或标头中，但决不能出现在URL中。 如果需要通过GET方法传递敏感数据，请将其放在标头中。
这是不可能的：例如.com /控制器/ 123 /操作？apiKey = a53f435643de32
您可以：例如.com / controller / 123 / action
标头：主持人：example.com
用户代理：Mozilla ...
X-API密钥：a53f435643de32
规则十二
考虑防范CSRF攻击
您可以
在此处阅读有关所有保护类型的更多信息，因此，使用CSRF令牌被认为是降低此类攻击风险的最流行方法。
规则十三
探索您的框架
如果使用任何框架在应用程序中实现REST，则应该研究它，而不是像通常那样盲目地使用它。 仔细阅读文档，尤其是安全性部分。 不要让它使用默认设置！ 每个框架都有其自己的细微差别，尤其是在安全性方面，因此了解它们非常重要。