去年秋天。一个伪装成NFT空投的DApp在tpwallet内置浏览器里弹出“验证钱包”按钮。点下去，页面悄悄往DOM里塞了一段script标签，尝试去读取window.ethereum的账号列表。脚本没跑起来是tpwallet防跨站脚本的CSP策略直接掐断了这个请求。用户只看到按钮转了两圈，然后页面白屏。资产没丢，助记词也没弹出来。攻击不算新鲜。跨站脚本（XSS）在普通网页上顶多偷个Cookie的，在钱包浏览器里，它能碰的东西太要命了，注入假的签名弹窗、替换收款地址、。
甚至伪造DApp连接请求。我见过一个案例，恶意脚本把“确认转账”按钮的点击事件绑到了另一个合约上。用户以为是领空投，实际签了授权。
tpwallet防跨站脚本要处理的，就是把戏。拆开看。tpwallet的做法不复杂，执行得细。内置浏览器对每个DApp页面启用了严格的CSP，禁止内联脚本和未备案的外部域。iframe被单独扔进沙箱，不能访问父窗口的window对象。更很重要的是任何尝试去调用window.ethereum的请求，都要经过一层RPC代理了，脚本拿不到原始接口。tpwallet防跨站脚本的另一个细节是我试过在一个测试页里写document.cookie，返回的是空字符串。
这算个小细节的，能说明问题。从开发人员角度看。防跨站脚本不是加个HTTP头就完事。
tpwallet把签名请求和页面渲染隔离开了是页面只能发起请求，签名动作在原生层确认。这等于把XSS的攻击面砍掉一大半。用户端也有代价了，有些老DApp的复杂交互会报错，得手动降级。我个人判断，取舍值得的。钱包里最值钱的是私钥，不是便利性。
一个脚本能随便读DOM的环境，再流畅也不敢用的。
