论为何要采用应用和 API 安全一体化战略
显而易见的一点是，应用和 API 安全变得愈发专业化。API 不再仅仅是基于 URI 的应用入口。API 已经发生演变，成为了一种有自身安全需求的独立实体。
这些安全需求大多与 API 交互的性质有关。换言之，API 需要按事务进行授权。这点与应用明显不同，应用通常按会话进行授权。
API 的交互率也较高，并伴有一些其他特点，致使保护 API 这件事面临着一些独特挑战。
| App/应用 | API | |
|---|---|---|
| 报文格式流畅度/Message format fluency | HTML、JSON、XML | ProtoBuf、JSON、GraphQL、binary/二进制、XML、data formats/数据格式 |
| 交互/Interactions | 静态/Static，变化不频繁/infrequent change | 动态/Dynamic，频繁变化/frequent change |
| 数据/Data | 结构型/Structured、事务型/transactional | 非结构型/Un/structured、流式/streaming 和事务型/transactional |
| 用户/User | 人类/Human | 软件/Software、人类/human |
| 用户代理/User-agent | 浏览器/Browsers、应用/apps | 软件/Software、设备/device、脚本/scripts、应用/apps、浏览器/browsers |
| 身份验证/Authentication | 按会话/Session-based | 按事务（更像零信任）/Transaction-based(more ZT like) |
| 协议流畅度/Protocol fluency | HTTP/S、QUIC | gRPC、WebSocket、HTTP/S、QUIC |
应用和 API 的比较，展现了因为哪些不同之处而造成了安全需求差异。
尽管如此，应用和 API 也存在着共同的安全风险，在实施安全解决方案时也需要对这些风险加以考虑。例如，最近更新的 2023 年十大 API 安全风险清单就明确提及了一组与应用共有的次要风险类别：
- 身份验证/授权控制薄弱
- 配置错误
- 业务逻辑滥用（撞库攻击或帐户接管）
- 服务端请求伪造 (SSRF)
除了这些风险外，还有大量针对可用性的攻击，也就是应用和 API 都会遇到的 DDoS 攻击，因为它们通常都依赖于 TCP 和 HTTP，而这两者都会受到各种旨在破坏访问和可用性的攻击。
为解决保护应用、API 和基础设施（为两者提供支持）安全挑战的一种方法是部署多种解决方案：Bot 和欺诈防御、DDoS 防护、应用安全和 API 安全。这种做法固然能解决安全挑战，但也带来了运营挑战，使许多安全相关任务变得更加复杂，例如策略变更管理和应对威胁（同时影响应用和 API）。复杂性不仅会阻碍安全性，同时也会制约速度。
根据我们的年度研究，及时应对新出现的威胁是采用安全即服务的首要驱动因素。每个解决方案都需要修复、更新或部署新策略来缓解新出现的威胁，这种做法不仅耗时，同时也增加了配置错误或失误的几率。因此，缓解威胁的时间会随着复杂性的增加而延长，特别是当企业在多个环境（混合 IT）中运行并利用每个环境的安全解决方案时。使用数学公式来计算时间是线性还是指数增长其实毫无意义，原因在于时间的延长对应对迫在眉睫的威胁本身就是一种最大的阻碍。
因此，更妥善的一种方法是将解决方案结合起来，从而共享操作和安全管理，获得专门应对威胁的功能，同时允许采用特定的安全策略来处理应用和 API 特有的协议和有效负载。
这就需要制定应用和 API 安全一体化战略，在共享通用功能的同时，可以提高应用或 API 的粒度和专业性。究其根本，Bot 对数据质量、交付成本及对应用和 API 风险状况带来的影响会成为一类问题。DDoS 同样如此。为解决同样的问题而部署双倍数量的服务，在所有衡量标准中都不能称之为高效。
无论是从运营层面，还是从经济和架构层面来看，采用应用和 API 安全一体化战略都不失为一项明智之举。