本文介绍一种基于 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 安全策略的重要技术手段。
