本文讨论了一个通用的安全框架，以保护我们的REST API免受不同类型的攻击，例如OWASP十大威胁，未经授权的访问，拒绝服务攻击，屏蔽机密数据等，同时还确保API满足全渠道安全的需求。

管理API安全性

API安全涉及端到端的安全数据，包括安全性，来自客户端的请求，通过网络到服务器/后端，服务器/后端准备和发送的请求，通过网络的返回结果，最后到达客户端。因此，API安全性大致分为四类，如下所述，并在后续章节中深入讨论：

1.运输安全中的Transit / Data中的数据

• a.在客户端和API网关之间保护动态数据
• b.在API网关和后端服务之间保护动态数据

2.访问控制和防止拒绝服务（DoS）攻击的安全性

3.身份验证和授权：使用OAuth 2.0或OpenID Connect准确识别用户信息

4.数据保密和屏蔽个人身份信息（PII）

下图描绘了上述类别以及端到端保护API的各种方法：

访问控制和防止拒绝服务（DoS）攻击的安全性

1.网络级防御：如果API网关托管在云服务中，则应利用云提供的DDoS防御机制，例如目前由Apigee（谷歌）部署和运营的Apigee Edge托管云平台，GCP（Google Cloud Platform） ）和AWS（亚马逊网络服务）利用两个云托管提供商在网络级别提供的DDoS防御。

2.内容交付网络： Akamai，Neustar和Rackspace等CDN可用于缓解/减少对API的DDoS攻击。

3.机器人检测：各种API管理平台已经提供了自动机器人服务，可以关注API流量，识别任何恶意/不需要的请求，并生成警报/阻止恶意请求到达API网关，例如Apigee（谷歌）提供机器人检测服务称为Apigee Sense。Sense是一种智能数据驱动的API安全产品，可检测并保护API免受恶意或不需要的流量的侵害。Sense通过自动识别可疑的API客户端行为提供另一层保护，管理员可以根据这些行为应用纠正措施以维护用户体验并保护后端系统

4.策略实施：应在API客户端和客户后端之间的API代理上实施策略，以限制对合法用户的API访问。以下策略强制实施必须保护API免受恶意黑客攻击：

• a.API速率限制：API速率限制适用于减少导致拒绝服务的大量API请求，还可以减少潜在的暴力攻击或滥用服务。应考虑在API代理处应用以下API速率限制机制：
• b.每个应用程序或每个API的API速率限制：每个API或应用程序只能访问服务，以定义每个速率限制窗口的请求数。
• c.每个GET或POST请求的API速率限制：允许的访问请求可能因每个时段的GET或POST请求而异。

5.正则表达式保护：应根据预定义的正则表达式（如DELETE，UPDATE和EXECUTE）评估传入请求的URI路径，查询参数，标头，表单参数，变量，XML有效负载或JSON有效负载。任何这些预定义表达式的存在应被视为威胁，并且应拒绝请求。有关要验证的正则表达式，请参阅OWASP前10名。

6.JSON输入验证：应执行对PUT / POST / DELETE请求的有效负载的JSON验证，以通过指定各种JSON结构的限制（例如最大深度，最大对象条目数，最大字符串长度）来最小化内容级攻击所带来的风险名称，数组中允​​许的最大元素数。等等

7.XML输入验证：应执行针对PUT / POST / DELETE请求的有效负载的XML验证，以使用以下方法基于配置的限制和针对XML威胁的屏幕API检测XML有效负载攻击：

• a根据XML架构验证消息（.xsd）
• b评估特定黑名单关键字或模式的消息内容
• c在解析这些消息之前检测损坏或格式错误的消息

8.请求验证:

• a.输入HTP动词验证：正确限制允许的动词，使得只有允许的动词起作用，而所有其他动词返回正确的响应代码（例如，403 Forbidden）。
• b.标头验证：应根据API支持的功能显示验证Content-Type，Accept，Content-Length等标头。此外，还应执行针对强制标头（如授权，API特定标头）的验证。
• c.验证传入的内容类型：对于PUT / POST / DELETE请求，传入请求和Content-Type标头值的Content-Type（例如，application / XML或application / JSON）应该相同。缺少Content-Type标头或意外的Content-Type标头应导致API拒绝具有406 Not Acceptable返回的内容。
• d.验证返回参数类型：不要简单地将Accept标头复制到返回的Content-type标头。如果Accept标头没有明确包含允许类型之一，则拒绝请求（理想情况下，使用406 Not Acceptable返回）。
• e.处理不支持的资源：正确地限制允许的资源，使得只有暴露的资源工作，而所有其他未实现的资源返回适当的响应代码，例如未知资源。
• f.访问控制：可以将策略配置为允许来自特定IP，域或区域的请求。网关拒绝未通过这些标准的请求。

身份验证和授权

通常，身份验证和授权同步使用。

• a.身份验证用于标识最终用户。
• b.授权用于对已识别用户有权访问的资源的访问权限。

在API中，OAuth和OpenID Connect是最常用的机制，通过利用现有的IAM基础架构来保护API端点，而不是每次都存储用户名和密码时构建单独的系统。这两个协议都针对现有IAM系统对用户进行身份验证，以交换访问密钥，该密钥进一步用于访问API资源。

OAuth

OAuth=使用访问密钥委托访问，通常是OPAQUE Token。

OAuth 2.0授权框架使第三方应用程序能够获得对HTTP服务的有限访问权限。如果你代表用户存储了受保护的数据，则不应在网络上传播密码以获取对其的访问权限。使用OAuth可让你的用户访问其数据，同时保护其帐户凭据。

• 1.OAuth不是身份验证协议。

这是一种授权协议。由于认证通常在发布访问密钥之前发生，因此很容易考虑接收任何类型的访问Token证明已发生这种认证。但是，仅仅拥有访问Token并不能告诉客户任何东西。在OAuth中，Token被设计为对客户端不透明，但在用户身份验证的上下文中，客户端需要能够从Token中获取一些信息。此问题源于客户端不是OAuth访问Token的目标受众。相反，它是该Token的授权者，并且观众实际上是受保护的资源。

• 2.由于访问Token可以交换一组用户属性，因此很容易认为拥有有效的访问Token足以证明用户已通过身份验证。

在某些情况下，这种假设是正确的，其中Token是在授权服务器上进行身份验证的用户中新建的。但这不是在OAuth中获取访问Token的唯一方法。刷新Token和断言可用于在没有用户存在的情况下获取访问Token，并且在某些情况下，访问授权可以在用户不必进行身份验证的情况下发生。

• 3.由于OAuth是一种委托协议，因此这是其设计的基础。

这意味着如果客户端想要确保身份验证仍然有效，那么仅仅为了再次交换用户属性的Token是不够的，因为受OAuth保护的资源（身份API）通常无法告知用户有没有。

“不透明” Token：

许多OAuth 2.0实现返回OPAQUE字符串以换取用户凭据，也称为访问密钥。这些密钥还用于访问API资源。不透明Token不是将用户身份和声明存储在密钥中，而是简单地引用具有数据的数据库。像Redis这样的快速存储，像Cassandra这样的NoSQL数据库非常适合利用内存进行有效负载的I / O查找。由于角色是直接从数据库中读取的，因此可以更改角色，一旦更改通过后端传播，用户就会看到新角色。

OpenID Connect

OpenID Connect =使用ID密钥和访问密钥的用户身份+委派访问  。

OpenID Connect =使用OAuth进行用户身份验证的标准。

1.OpenID Connect直接构建在OAuth 2.0上，在大多数情况下，它与OAuth基础架构一起（或在其上部署）。

2.除OAuth访问和刷新Token外，它还为客户端提供OpenID Connect ID密钥。ID Token是签名的JSON Web Token（JWT），它与常规OAuth访问Token一起提供给客户端应用程序。

JSON Web Token：

JWT Token实际上是一个完整的JSON对象，它已经过base64编码，然后使用对称共享密钥或使用公钥/私钥对进行签名。JWT可以包含主题或user_id之类的信息，发布Token时以及过期的信息。通过秘密签名，确保只有具有秘密访问权限的系统才能生成Token。但要记住的一件事是，在JWT签名时，JWT通常不加密（尽管你可以选择加密它）。这意味着任何有权访问Token的人都可以读取Token中的任何数据。因此，好的作法是在Token中放置标识符，例如user_id，而不是个人身份信息，如电子邮件或社会安全号码。此外，它们应使用TLS通过加密通道传递。

JWT限制：

禁止用户或添加/删除角色有点困难，因为它角色可能需要不断增删。请记住，JWT有一个预定义的到期时间。由于Token存储在客户端，因此即使在数据库中将发出JWT的用户标记为已禁用，也无法直接使Token无效。相反，你必须等到它过期。这可能会影响你的体系结构，尤其是在设计可能被一个高级用户或需要禁止欺诈用户的电子商务应用程序的公共API的情况。

虽然有一些解决方法，例如，如果你关心的是禁止被入侵的Token或用户，你可以拥有一个Token或user_ids的黑名单，但这可能会将数据库重新引入你的auth框架。建议的黑名单方法是确保每个Token都有JTI声明（或者可以存储在数据库中的JWT Id）。假设你想要使用的Token数量远远小于应用程序中的用户数量，这会比较容易扩展。

对于具有许多角色的企业应用程序（如管理员，项目所有者，服务帐户管理员），切换用户角色可能不会对JWT产生直接影响。需要特别考虑一下管理员正在修改其他人的授权角色（例如他/她的直接报告）的情况。因此，修改后的用户甚至不知道他/她的角色在没有刷新JWT的情况下已经改变。

数据保密和屏蔽PII 

密码、安全Token和API密钥不应出现在URL中，因为这可以在Web服务器日志中捕获。此外，应随时随地屏蔽用户ID、密码、帐号、银行卡号等个人身份信息，包括交易和审核日志。

公共API的安全实践

公共API旨在公开非敏感且只读的数据（例如Weather API），并且不希望添加任何用户身份验证/授权（因为数据是用户独立的），建议将以下几点合并到API中，以免出现威胁或者滥用：

1.在IP地址级别应用速率限制策略。

2.对公共API密钥应用API密钥验证。API密钥可以存储在网关本身，而不会将其暴露给客户端。应用API密钥验证的好处是，在尝试对API进行DoS攻击以及阻止黑客失败的其他策略时，可以通过使密钥无效来随时阻止通过此公共API的网关流量。虽然这会阻止所有API流量，包括有效呼叫，但基础设施受到保护。

3.应用配额策略（单个或多个配额）以应用API使用限制。

4.如果API旨在为特定地理位置提供服务器流量，则应在地理级别（县/地区等）应用IP过滤。

5.仍应推动开发人员进行一次性注册，并使用自己的API密钥调用API。

结论

API是在企业内部和跨企业集成应用程序的好方法。它们快速且易于实施。但与此同时，如果没有妥善保护，它们可能会很危险，从而使整个企业面临将其暴露给黑客的风险。因此，API安全性应该在实际开始API开发之前进行良好的架构和设计。没有经过验证的技术会让API危险，但精心设计的API可以极大地降低安全风险，企业可以从API中获益而不受威胁。

参考资料：Vivek Yadav ，Ensuring the Security of Your APIs?

原文链接：https://dzone.com/articles/how-do-you-ensure-security