为了搞懂Web2支付到底怎么运转，我搭了一套Stripe沙盒环境，跑了一遍完整的结账流程。支付成功之后，我打开浏览器的开发者工具，想看看数据到底是怎么流动的——结果发现了521个网络请求，其中129个来自一个叫hCaptcha的东西。
我问了Claude才知道，这是Stripe用来识别欺诈的机制。它会记录你移动鼠标、点击输入框这些行为，分析操作模式像不像真人。这个发现让我更想弄清楚：整个支付链条里，到底哪些数据被传到了哪里？隐私风险有多大？
逐个检查521个请求显然不现实。Claude提醒我可以用HAR文件——一种记录浏览器所有网络活动的格式。说实话，干了这么多年工程，我今天才知道这东西。HAR文件通常用来调试性能问题、排查认证故障，还能配合Playwright做端到端测试，把用户操作流程录下来回放。
我导出了自己的HAR文件，打开后第一眼就看到了明文存储的信用卡号、CVC安全码和有效期。虽然这只是Stripe的测试卡号，但这个画面让我后背发凉：如果是真实支付场景呢？
冷静下来之后我意识到，HAR文件本身只保存在本地，风险主要来自分享。但问题恰恰在这里——调试时人们经常把HAR文件发给同事或客服。2023年Okta的那起安全事故就是这样发生的：一名员工把HAR文件存到了个人Google账户里调试问题，账户被攻破后，攻击者拿到了文件里的会话数据，直接冒充了多家客户的用户身份。我的"灾难想象"并不是杞人忧天。
回到支付流程本身。按照Stripe的安全架构设计，我的服务器本来就不会接触到支付信息。TLS加密保证了传输过程中即使被截获也无法读取，但HAR文件记录的是浏览器加密之前看到的内容。好在这些数据随后会被Token化，就算泄露也无法直接使用。
这次排查让我意识到一个盲区：我们花了大量精力保护传输和存储安全，却容易忽略调试工具本身留下的痕迹。HAR文件的设计初衷是解决问题，但它同时完整复刻了用户的敏感操作——包括那些本应被加密隐藏的内容。在安全和便利之间，这道选择题没有标准答案，但至少得先知道自己在选什么。
热门跟贴