16、WebKit 的安全机制：同源策略（SOP）、跨站脚本（XSS）防护、内容安全策略（CSP）、沙箱与权限管理
聊到浏览器内核，安全永远是个绕不开的话题。我做了这么多年Android系统，见过太多因为WebView安全配置不当导致的应用被攻破案例。说白了，WebKit的安全机制就像是一栋大楼的安保系统——有门禁、有监控、有防弹玻璃，还有独立的保险柜。今天我们就来拆解这四道防线。
16.1 同源策略（SOP）—— 浏览器的“户籍制度”
同源策略，英文叫Same-Origin Policy，简称SOP。它是浏览器最基础、最核心的安全模型。什么叫“同源”？协议、域名、端口三者完全一致，才算同源。
举个例子：
页面A：https://example.com:443/page.html
页面B：https://example.com:443/api/data → ✅ 同源
页面C：http://example.com:80/api/data → ❌ 协议不同
页面D：https://api.example.com:443/data → ❌ 域名不同
我刚开始接触WebKit源码时，觉得SOP就是个简单的“禁止跨域读”规则。后来踩了坑才发现，它远比想象中复杂。比如，document.domain可以放宽同源限制，但只适用于同一个顶级域名下的子域。还有，window.postMessage可以跨域通信，但你必须手动校验来源。
我的经验：在Android WebView中，默认是开启SOP的。但如果你调用了setAllowFileAccess(true)，并且加载了本地文件，那么file://协议下的页面可以访问其他本地文件。这是个常见的安全漏洞点。我曾经在一个金融类App里发现，开发人员为了方便调试，打开了文件访问权限，结果上线后被安全团队打了回来。
16.2 跨站脚本（XSS）防护—— 别让恶意脚本“混进来”
XSS攻击，说白了就是攻击者把恶意脚本注入到你的页面里。它分三种：反射型、存储型、DOM型。WebKit对XSS的防护，主要体现在两个方面：
- XSS Auditor（已废弃）：Chrome曾经内置的XSS过滤器，会在URL或请求体中检测反射型XSS。但后来因为性能问题和绕过方式太多，被移除了。
- 内置的HTML解析器防御：WebKit的解析器在遇到
<script>标签时，会检查上下文是否合法。比如，在<textarea>里出现的<script>不会被当作脚本执行。
但说实话，浏览器自带的XSS防护只是“兜底”的。真正的防线在前端和后端。我见过太多团队把希望寄托在浏览器的XSS过滤器上，结果被各种奇技淫巧绕过。
避坑指南：我曾经接手过一个项目，后端直接把用户输入拼接到HTML里返回，前端也没有做任何转义。结果一个用户提交了<img src=x onerror=alert(1)>，整个页面就炸了。记住：永远不要信任用户输入！
16.3 内容安全策略（CSP）—— 给浏览器一份“白名单”
CSP，全称Content Security Policy。它通过HTTP响应头或<meta>标签，告诉浏览器哪些资源是允许加载的。说白了，就是给浏览器一份“白名单”。
一个典型的CSP策略长这样：
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src *;这条策略的意思是：
default-src 'self'：所有资源默认只能从当前域名加载script-src：脚本只能从当前域名和trusted.cdn.com加载style-src：样式可以从当前域名加载，也允许内联样式img-src *：图片可以从任何地方加载
我在项目中强烈建议使用CSP。它虽然不能解决所有安全问题，但能有效阻止大部分XSS和数据注入攻击。比如，即使攻击者注入了<script>alert(1)</script>，如果CSP不允许内联脚本，这个脚本就不会执行。
我的习惯：在开发阶段，我会先用Content-Security-Policy-Report-Only模式，只报告违规不阻止。等确认策略没问题了，再切换到强制模式。这样可以避免误伤正常功能。
16.4 沙箱与权限管理—— 把页面“关进笼子”
沙箱（Sandbox）是WebKit最底层的安全机制。它把每个渲染进程隔离起来，即使某个页面被攻破，攻击者也无法直接访问系统资源或其它进程的数据。
在Android WebView中，沙箱机制主要体现在：
- 进程隔离：每个WebView实例运行在独立的渲染进程中
- 权限控制：通过
WebSettings控制JavaScript、文件访问、地理位置等权限 - iframe沙箱：通过
sandbox属性限制iframe的能力
iframe的sandbox属性非常强大。它可以单独控制：
<iframe src="https://untrusted.com" sandbox="allow-scripts allow-same-origin"></iframe>上面的代码只允许iframe执行脚本，并且保持同源。但注意，allow-scripts和allow-same-origin同时使用时，可能会绕过沙箱限制。这是个经典的安全陷阱。
我曾经踩过的坑：在一个混合开发App中，我们加载了第三方H5页面。为了安全，我们给iframe加了sandbox属性。但后来发现，第三方页面需要调用window.open打开新窗口，而sandbox默认禁止了弹窗。我们不得不加上allow-popups，但又担心被滥用。最后我们通过shouldOverrideUrlLoading拦截了所有弹窗请求，手动校验后才放行。
16.5 知识体系总览
下面这张图，是我自己总结的WebKit安全机制分层模型。你可以把它当作一个“安全地图”：
16.6 四道防线的协同工作
这四道防线不是孤立的，它们协同工作，形成纵深防御。我举个例子你就明白了：
假设一个攻击者想通过XSS攻击窃取用户Cookie。首先，SOP会阻止跨域读取Cookie。但如果攻击者成功注入了脚本（绕过了XSS防护），CSP可以限制脚本只能加载白名单内的资源，防止数据外传。即使CSP配置有误，沙箱机制也会把攻击限制在渲染进程内，无法影响系统其它部分。
| 安全机制 | 防御目标 | 绕过方式（举例） | 我的建议 |
|---|---|---|---|
| SOP | 跨域数据读取 | JSONP、CORS配置不当 | 严格校验CORS来源 |
| XSS防护 | 恶意脚本注入 | 编码绕过、DOM clobbering | 前后端双重转义 |
| CSP | 资源加载控制 | unsafe-inline、JSONP劫持 | 使用nonce或hash |
| 沙箱 | 进程/权限隔离 | allow-scripts+allow-same-origin | 最小权限原则 |
核心要点：安全没有银弹。SOP、XSS防护、CSP、沙箱这四道防线，每一道都有它的局限性。真正的安全，是让攻击者需要同时突破所有防线才能得手。我在做安全评审时，会逐层检查：SOP配置是否正确？用户输入是否转义？CSP是否足够严格？沙箱权限是否最小化？
嗯，关于WebKit的安全机制，今天就聊到这里。这些内容看起来有点抽象，但你在实际项目中一定会遇到。下次我们聊聊更具体的东西——WebKit的网络栈和资源加载优化。