当前已经落实的安全措施
- 网页端与公开接口当前都使用 HTTPS 域名,减少明文传输风险。
- 浏览器端当前只保存用户名回填和验证码验证状态,不把账号密码写入 `localStorage`。
- 公开网页提交链路按 IP 做了基础限流,降低同一来源在短时间内高频滥用的概率。
- 根据当前代码审查,公开网页提交流程不会把密码写入 `step_records` 记录表。
- 小米运动备用提交流程中的关键请求日志对密码做了掩码处理,而不是直接把原文打印出来。
这意味着什么
当前代码已经具备基础的传输、限流和“浏览器不存密码”的边界,但这仍然不等于整个链路已经达到强安全状态。
当前代码已经具备基础的传输、限流和“浏览器不存密码”的边界,但这仍然不等于整个链路已经达到强安全状态。
仍需继续整改的风险点
重要风险
当前代理提交通道的代码会把账号和密码拼到代理请求 URL 中。如果生产环境启用了第三方代理, 这些参数可能进入上游访问日志、代理日志或其他审计链路,应该尽快整改。
当前代理提交通道的代码会把账号和密码拼到代理请求 URL 中。如果生产环境启用了第三方代理, 这些参数可能进入上游访问日志、代理日志或其他审计链路,应该尽快整改。
- 代理 URL 带参风险:当前 `stepSubmitter` 链路使用查询参数构造代理请求,敏感字段不适合长期沿用这种传输方式。
- 第三方通道可信度:如果启用了外部代理接口,运营方应只保留受信任通道,并审查代理服务自己的日志与保留策略。
- 公开说明不足的问题:本次新增了隐私说明、安全说明、FAQ 和使用指南,但服务器侧仍需持续同步这些文档口径。
- 数据清理策略待补充:仓库中未看到公开网页提交流程对应的自动清理策略说明,生产环境应补充周期性清理与审计机制。
运营侧优先级建议
- 优先把代理链路从 URL 查询参数迁移到更安全的服务端提交方式,例如 POST Body 或站内直连提交流程。
- 只保留受信任的代理服务,关闭不必要的第三方通道,并检查 Nginx / 应用日志中是否记录了敏感参数。
- 建立清晰的留存与清理策略,明确账号、日志和失败记录的保留周期。
- 每次改动公开网页或服务端逻辑时,同步更新安全说明和部署文档,避免文档与线上行为脱节。
给使用者的建议
- 优先使用独立测试账号,不要复用重要站点或常用邮箱的长期密码。
- 不要在公共电脑、共享浏览器或不受信任网络环境中提交账号信息。
- 使用完成后及时关闭页面,并在必要时清除浏览器站点数据。
- 如果你对当前提交通道的可信度没有把握,请不要继续使用公开网页提交流程。