Bounce Tracking是一种利用重定向链、第一方Cookie和跨站导航实现用户跨站识别的隐蔽追踪技术。其核心是通过跳转至跟踪器域名设置/读取第一方Cookie，再重定向回原页面并编码标识符到URL，从而绕过第三方Cookie限制；与普通跳转本质区别在于“跳完还带状态回来”，且无用户授权，属非显式、非登录类行为。
HTML 本身没有 bounce tracking 这个标准术语，它不是浏览器原生功能，而是近年安全研究中对一类**利用重定向链 + 第一方 Cookie + 跨站导航行为**实现用户跨站识别的隐蔽追踪技术的统称。它和传统第三方 Cookie 跟踪不同——当第三方 Cookie 被禁用后，攻击者改用“跳出（bounce）”方式绕过限制：先跳到自己控制的域名（设第一方 Cookie），再立刻重定向回目标页，并把 Cookie 值编码进 URL 参数。这种模式在 Safari、Firefox、Brave 和 Edge 的隐私策略下仍可能生效。
什么是 Bounce Tracking？它和普通跳转有啥区别
关键不在“跳”，而在“跳完还带状态回来”。典型流程是：
- 用户在
site-a.com点击一个广告链接 → 浏览器跳转到tracker.com/bounce?return=site-a.com%2Fpage -
tracker.com检查是否存在自己的第一方 Cookie（比如id=abc123），若无则生成并写入 - 服务器立即 302 重定向回
site-a.com/page?id=abc123（或通过postMessage回传） -
site-a.com的 JS 读取 URL 参数或接收消息，完成用户 ID 关联
与普通跳转的区别在于：它刻意制造一次“可控的第一方上下文”，只为提取/注入可跨站携带的标识符。这不是用户主动登录（如 OAuth），也没有显式授权提示。
如何检测页面是否被用于 Bounce Tracking
重点看三类痕迹，不需要逆向 JS：
立即学习“前端免费学习笔记（深入）”；
- 检查页面中是否存在形如
location.href = "https://tracker.example/bounce?return=" + encodeURIComponent(window.location.href)的硬编码跳转逻辑 - 监听
beforeunload或visibilitychange事件里是否有可疑的fetch()或Image().src请求发往非本站域名（尤其是短域名、拼写近似域名） - 用开发者工具的 Network 面板过滤
document类型请求，观察是否有从当前页发起、但响应头含Location: https://xxx/bounce的 302 跳转 - 注意那些“看似无害”的 iframe：如果它 src 是
https://tracker.net/frame.html?mode=bounce，且父页 JS 向其 postMessage 了 URL 或 token，就高度可疑
前端能做的有效缓解措施有哪些
纯前端无法根除 bounce tracking（服务端配合才完整），但可显著提高攻击成本、降低成功率：
- 避免在 URL 中暴露敏感标识：不要把
user_id、session_id直接拼进跳转链接；改用短期有效的、一次性的 token（如 JWT withexp≤ 30s） - 校验
document.referrer和navigation.type：若为navigation.type === 'navigate'且referrer来自陌生域名，可延迟加载追踪脚本或降级埋点粒度 - 拦截可疑重定向：对
window.location.assign/replace做代理封装，记录跳转前 URL 和目标，命中黑名单域名时 warn 或 abort（需权衡兼容性） - 禁用
document.cookie写入非当前 host 的能力：可通过Object.defineProperty(document, 'cookie', { writable: false })封锁（仅限调试/高安全场景，会破坏合法登录） - 优先使用
SameSite=Lax+Secure+HttpOnly设置所有 Cookie，让 bounce 页面即使拿到 Cookie 也无法读取值（除非服务端主动回传）
为什么不能只靠 SameSite=Strict 或屏蔽第三方 Cookie
因为 bounce tracking 本质是**第一方行为**：tracker.com 对自己是第一方，site-a.com 对自己也是第一方。SameSite 属性只约束“跨站请求中是否发送 Cookie”，不约束“用户主动导航到 tracker.com 后它自己怎么操作”。而浏览器禁用第三方 Cookie 后，tracker.com 只需换个姿势——变成“用户临时访客”，照样能种下第一方 Cookie。
真正容易被忽略的点是：很多团队以为关掉第三方 Cookie 就安全了，却没意识到自己页面上的跳转链接、iframe 加载逻辑、甚至 fetch() 的目标地址，都可能成为 bounce chain 的一环。防御必须覆盖整个导航生命周期，而不是只盯着 Cookie 属性。
