本文介绍一种基于 Object.defineProperty 拦截 document.cookie 写入操作并解析调用栈的方法，可在浏览器环境中识别外部脚本（如来自 domain B）在当前页面（domain A）设置 Cookie 的确切来源，适用于前端安全审计与第三方行为监控。
本文介绍一种基于 `object.defineproperty` 拦截 `document.cookie` 写入操作并解析调用栈的方法，可在浏览器环境中识别外部脚本（如来自 domain b）在当前页面（domain a）设置 cookie 的确切来源，适用于前端安全审计与第三方行为监控。
在 Web 开发与安全分析中，常需确认某个 Cookie 是否由第三方脚本（例如嵌入的广告 SDK、分析工具或跨域组件）所设置。由于同源策略限制，javaScript 无法直接读取 document.cookie 的元信息（如 Domain、SameSite 或设置来源），也无法通过标准 API 获取“谁设置了这个 Cookie”。但我们可以利用 javascript 的属性拦截能力，在 Cookie 被写入的瞬间捕获调用上下文，从而推断其真实来源。
核心原理：劫持 document.cookie 的 setter
document.cookie 是一个具有 getter 和 setter 的 accessor 属性。我们可通过 Object.defineProperty 重定义其 set 行为，在每次赋值前主动捕获当前执行栈（stack trace）。只要第三方脚本（如 https://domain.b/script.js）执行了类似 document.cookie = “key=value” 的操作，该拦截器就能触发，并输出完整的调用链。
以下为生产可用的调试代码（兼容 chrome、firefox、edge）：
<script type="text/javascript"> function monitorCookieSource() { const originalDescriptor = Object.getOwnPropertyDescriptor(Document.prototype, 'cookie'); if (!originalDescriptor || !originalDescriptor.set) return; Object.defineProperty(document, 'cookie', { set: function(value) { // 尝试捕获调用栈（Chrome/Edge 支持 Error.captureStackTrace；Firefox 需 fallback） const stack = (function() { try { const err = new Error(); if (typeof err.stack === 'string') { return err.stack; } } catch (e) { // 忽略异常，返回空栈 } return ''; })(); // 提取最可能的调用者（倒数第二行通常是实际发起脚本，最后一行是拦截器自身） const lines = stack.split('n').filter(l => l.trim().startsWith('at ') || l.includes('@')); const callerLine = lines.length >= 2 ? lines[1].trim() : 'unknown'; console.info('[Cookie Source Monitor]', { value: value.substring(0, 100), // 防止过长日志 caller: callerLine, timestamp: new Date().toISOString() }); }, get: originalDescriptor.get }); } // 启用监控（建议在页面 <head> 中尽早执行） monitorCookieSource(); </script>实际效果示例
当 domain.b/script.js 中执行：
立即学习“Java免费学习笔记（深入）”；
// https://domain.b/script.js document.cookie = "tracking_id=abc123; domain=domain.a; path=/";控制台将输出类似内容：
{ "value": "tracking_id=abc123; domain=domain.a; path=/", "caller": "at https://domain.b/script.js:42:5", "timestamp": "2024-06-15T10:23:45.789Z" }✅ 关键结论：caller 字段中的 URL 即为 Cookie 设置行为的实际发起源（即 domain.b），而非当前页面域名（domain.a）——这正是你所需的“精确来源信息”。
注意事项与限制
- ⚠️ 仅适用于写入时监控：该方法无法追溯已存在的 Cookie 来源，仅对后续 document.cookie = … 操作生效。
- ⚠️ 不突破同源策略：拦截本身不绕过任何安全机制，仅利用 JS 运行时可观测性，符合浏览器规范。
- ⚠️ 调用栈可靠性依赖浏览器实现：不同浏览器对 Error.stack 的格式略有差异（如 safari 可能省略行号），建议以 @https://… 或 at https://… 开头的 URL 片段作为主要判断依据。
- ⚠️ 生产环境慎用：此方案为调试用途，频繁重定义原生属性可能影响性能或与其他库冲突；上线前应移除或封装为条件启用（如 window.DEBUG_COOKIE_MONITOR = true）。
- ✅ 可扩展性强：可进一步结合 PerformanceObserver 监控资源加载，或与 CSP report-uri 联动，构建完整的第三方行为审计体系。
综上，虽然浏览器未提供原生的“Cookie 来源溯源 API”，但借助属性劫持与调用栈分析，开发者完全可以在前端精准识别跨域 Cookie 设置者——这是实施隐私合规检查、排查意外第三方写入、以及加固 Cookie 安全策略的重要技术手段。