多年来，我注意到一个有趣却也更令人困扰的现象：网络工程师和应用开发人员看待应用的方式存在差异。这一点体现在网络图中应用的呈现方式上；反过来，也体现在应用架构图中网络的呈现方式上。
不言而喻，双方对彼此的看法都过于简单。
安全领域也是如此。安全不仅要保护网络和应用，还要保护企业本身，其作用已变得至关重要。安全团队必须跳出典型架构图中的条条框框，真正了解应用。相当一部分（成功的）攻击发生在应用层。我们越晚认识到各类应用的独特特征，这些应用面临漏洞利用风险的时间就越长。
今天的讨论将重点介绍SPA。如果您想知道这个三字母缩略词的含义，它指的是“单页应用”。
SPA简介
单页应用顾名思义，就是以单个网页作为框架，承载与应用相关的所有任务。这种架构可追溯到Web 2.0时代。当时，AJAX开始用于“刷新”单个DOM（文档对象模型）元素，而无需重新加载整个页面。这项技术显著提升了性能，也成为现代单页应用的先驱。
这类应用的行为更接近移动应用：首次打开时加载客户端UI，之后与服务器之间仅传输数据。也就是说，每次调用服务器时只传输数据，UI的任何更改都在客户端完成。这大幅减少了往返传输的数据量，从而提升性能。这类应用使用API交换数据。
通常，我们一直假设其中大多数API都基于REST原则实现。这意味着每个对象（通常视为与单个UI元素关联）都有自己的API，可通过调用该API执行CRUD（创建、读取、更新和删除）事务。从安全角度看，这在一定程度上简化了问题，因为对于给定的API（URI）调用，可以预期数据采用特定格式。发送到“/update/product/123”的数据始终是同一种序列化对象，而发送到“/delete/order/4433”的数据则是另一种序列化对象。因此，可以沿用将特定策略与特定URI关联的传统做法来保护该API。
单一URI模式
现在，SPA可能遵循此模式，也可能不遵循。SPA领域的新兴实践既可以使用同一API执行事务，也可以采用更传统的函数到URI映射。对于采用单一URI模式的SPA，URI不会改变，但服务器之间来回传输的序列化对象会发生变化。
这与SOA/XML事务类似，其中使用单个端点（URI）调用多个函数。目标函数（端点）包含在序列化的XML数据中，有时也会插入自定义HTTP标头。该模型因此需要使用SOA/XML网关来接收请求，确定所调用的函数，然后将请求路由到正确的端点（服务器）。
对于SPA，可能需要处理多个API调用，也可能只需处理少量调用。无论哪种情况，都可能需要保护某种格式的数据（可能是XML，但更可能是JSON）。这意味着需要注意，内容本身可能带来风险。由于某些数据可能用于动态生成UI元素（或以其他方式在客户端操纵DOM），因此务必在每次提交时查找并清除潜在的恶意代码。
安全脱节
遗憾的是，如果使用单个URI为不同功能交换数据，将策略附加到URI的传统做法就无法奏效。事实上，这可能会破坏安全机制，因为此类策略通常经过训练，只接受特定的有效负载格式。API网关也经常将策略（路由、计量、访问）绑定到特定URI。这意味着，仅使用少量URI（API调用）来处理更多功能及不同数据格式的做法，可能会破坏现有安全机制。
这说明了为什么安全团队与开发人员（这里的dev不是指DevOps，而是开发人员）从编写第一行代码到部署的整个过程中开展更紧密的协作正变得日益重要。开发人员可以在早期采取一些措施，帮助安全团队更轻松地实施适当的防护，例如插入一个带有指示信息的HTTP标头，以便执行正确的策略。即使只是添加“X-Code: 'order'”这样简单的信息，也能丰富请求内容，使安全解决方案能够识别相关数据，并进一步扫描其中是否存在潜在的漏洞利用行为。
从架构角度看，这可能需要一个智能L7代理，用于提取代码并重写URI，然后将请求路由到适当的安全解决方案（WAF、API Gateway等）。如果智能L7代理能够解析JSON等数据格式，并且开发人员在每次交互中都加入可用于重写和路由的代码或端点名称，此方法同样适用。
理想情况下，将应用层安全机制集成到应用本身，可在性能与安全性之间取得更好的平衡。但这并非总能实现，有时需要采用创新的架构解决方案来实现安全目标。
安全需要团队协作
一般而言，开发人员在客户端与服务器之间分配各项职责的方式一旦发生变化，就会显著影响应用服务基础设施处理后续请求和响应的方式。安全团队、开发团队和应用服务基础设施团队都应参与整个软件开发生命周期（SDLC）。架构解决方案的实施也需要时间。如果拖到“最后阶段”才处理，产品上市时间可能会因此延后数天、数周，甚至数月。否则，产品可能会在缺少安全服务的情况下上市，进而带来相应的风险和后果。
从开发第一天起就开展协作，是确保应用投入生产时具备可用性、高性能和安全性的高效快捷方式。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。