钱包入口注入到哪些网页有规矩：CAIP-154 的安全上下文与内嵌框架判定表

网页连接钱包用的那个入口，通常由钱包扩展注进页面里。问题是：不是每一个网页、每一个页面角落，都配拿到这个入口。CAIP-154 就是给”钱包入口注入到哪儿”立规矩的一份文档，全称 Restrict Web3 Provider API Injection，状态 Draft，起草于 2022 年 10 月 19 日，作者名单同时覆盖浏览器实现与钱包实现两侧。它借用了 Web 平台一个现成的安全边界——安全上下文，把钱包接口当成”强力 API”来管。

安全上下文：一条判断式管住一大片

CAIP-154 的核心要求是：提供方对象（比如 window.ethereum，也包括 Solana 钱包适配器那一类）只在安全上下文里注入。判断方法很朴素，页面里调 window.isSecureContext，在 iframe 内部同样可以调。安全上下文覆盖 HTTPS 站点，也包括 HTTP 的 localhost；浏览器实现可以选择支持额外配置的可信来源——Chromium 系浏览器里那个”把不安全来源当作安全来源处理”的实验开关就是这类口子。规范还留了一句容易被忽略的话：提供方对象可以在无痕（隐身）窗口里保持可用，隐身不等于不注入。

钱包入口注入到哪些网页有规矩：CAIP-154 的安全上下文与内嵌框架判定表图 2 — 钱包入口注入到哪些网页有规矩：CAIP-154 的安全上下文与内嵌框架判定表 · 图 2

内嵌框架的三条分界线

真正影响日常使用（和日常故障）的是 iframe 规则，CAIP-154 写得很硬。第一，默认情况下 Web3 提供方 API 不得暴露给第三方 iframe——广告位、嵌入式小部件都属于这一类。第二，只要某个 iframe 里 window.isSecureContext 返回假，那里的提供方 API 必须是未定义状态，不是”存在但报错”。第三，第三方框架应当被挡住，但允许放行：iframe 标签写上 allow="ethereum" 或 allow="solana" 就可能获得入口，代价是实现方必须扩展 Permissions API 来支撑这个许可。同一份文档还处理了沙箱：一方框架如果带 sandbox 属性，提供方对象必须被挡；只有 sandbox="allow-same-origin" 这种写法允许在一方框架里注入，同时规范提醒 allow-same-origin 对第三方框架不起决定作用，第三方的去留由上面那条 allow 许可说了算。

它挡的是什么，顺手省的是什么

规范给出的例子是”合法 dApp 页面上的恶意广告”：广告所在的框架相对顶层站点是第三方，按这套规矩它拿不到钱包入口，也就没法越过去请求用户的资金或数据。另一半收益在隐私：提供方对象见页就注，等于给每个网页都发了一枚”这人装了钱包”的标记，恶意页面可以借它做浏览器指纹识别，把用户认成”Web3 用户”这一小撮人。挡住注入面，就是同时缩小攻击面和被追踪面。

测试向量：一张判定表读法

CAIP-154 附了一组手工测试用例，值得当判定表读。顶层 http://a.com 直接挡（不安全顶层）；顶层 HTTPS 放行；HTTPS 顶层里嵌一个同域 HTTP 框架，挡（框架自己不安全）；HTTP 顶层里嵌 HTTPS 框架，也挡（顶层已经不合格）；https://a.com 嵌 https://a.com，放行；嵌 https://b.com，挡（第三方且无许可）；子域 https://sub.a.com 同样算第三方被挡；顶层是 data: 或 file: 协议，一律挡。还有一条细则：一方框架同时写 allow-same-origin 和 allow-scripts 会被放行，但规范点名的 MDN 文档提醒这种组合允许框架摘掉自己的沙箱，属于不鼓励的写法。碰到”网页里连不上钱包”，拿这张表对照地址栏和嵌入结构，先判断是不是规矩如此，再怀疑钱包坏了。

开发者模式开关：只给本地开的一扇门

本地开发把 dApp 挂在 http://localhost 上，如果浏览器不把 localhost 当安全上下文，就会被上面的规则挡住。CAIP-154 给出的兼容出口是：钱包扩展可以考虑做一个”开发者模式”开关，只关闭针对 localhost 这一类来源的不安全检查，而且开关必须默认关闭。规范同时警告了这个开关的用法风险——如果把放行范围从 localhost 扩展到别的来源，“开一下开发者模式”就会变成用户被说服着绕过整道防线的入口。这一条与有的网页里钱包入口根本不存在：EIP-5593 说的安全上下文与内嵌框架边界讲的 iframe 安全上下文边界是同一族问题；入口注入的”谁先谁后”之争则见被反复覆盖的 window.ethereum：EIP-5749 给多钱包之争打的补丁。

用户端的三条实用判断

第一，连不上钱包先核地址栏协议：HTTP 的正式域名站点、file:// 打开的本地页面，本身就是注入名单之外。第二，凡是”钱包按钮嵌在别人页面里没反应”的场景，试着在新标签页里以顶层页面打开同一个 dApp，多半就有了——这是第三方框架被挡的典型症状。第三，别为了连某个站点随手开开发者模式或”不安全来源放行”，那等于把 CAIP-154 整份文档的假设撤销掉；用完记得关。

风险提示：本文是钱包接口机制科普，不构成投资建议；接口注入规则由浏览器与钱包实现分别执行，具体行为以你所用版本的现文为准，涉及大额资金的操作请在顶层页面、HTTPS 站点上完成并逐项核对签名内容。