page-agent 安全策略指南版本支持、漏洞报告流程与安全边界解析【免费下载链接】page-agentJavaScript in-page GUI agent. Control web interfaces with natural language.项目地址: https://gitcode.com/GitHub_Trending/pa/page-agent本指南基于开源仓库中的官方安全策略文档 docs/SECURITY.md系统讲解 page-agentJavaScript in-page GUI agent及其工作区包的安全维护承诺、漏洞报告规范、报告内容要求与披露政策并结合 浏览器扩展源码 等仓库实现深入解读项目真实的安全边界BYOK 架构、本地存储、令牌隔离、权限最小化与防御纵深。阅读本文后你将掌握如何判断自己使用的版本是否处于安全维护范围、如何正确且高效地提交一份可被维护者优先处置的安全漏洞报告以及项目源码中可审计的安全机制落点。一、受支持版本哪些版本会获得安全修复官方安全策略明确采用尽力而为best-effort的修复承诺支持范围如下表版本是否受支持main分支✅ 是page-agent及工作区包的最新 npm 发布版✅ 是更早的旧版本❌ 否两条关键结论只有main分支与最新发布版受保护。若你针对旧版本older releases提交问题维护者不会优先处理官方要求先升级到最新版本再报告仍存在的问题。安全修复的节奏是尽力而为并非 SLA 承诺。这意味着高风险使用方应在升级发布后尽快跟进补丁版本并在生产环境中避免长期停留在落后版本。判断你的版本是否在支持范围内查看main分支的最新状态以及 packages/extension/package.json、packages/core/package.json 等各工作区包package.json中version字段对应的最新 npm 发布版本。安全问题的复现与修复验证建议始终在main分支上进行。二、漏洞报告流程私有通道优先安全策略对披露渠道给出了硬性约束禁止通过公开的 GitHub issues、讨论区或 Pull Request 提交安全漏洞必须走 GitHub 的私有漏洞报告流程Private vulnerability reporting即在仓库安全策略页面点击Report a vulnerability按钮仅在私有报告渠道不可用时才允许提交一个最小化的公开 issue用于索取私有联系渠道且不得在公开 issue 中包含任何利用细节exploit details。这一设计符合行业主流漏洞披露惯例私有通道给维护者留出调查与修复窗口避免在补丁发布前将攻击面暴露给恶意使用者。一份高质量安全报告应包含什么官方要求报告必须包含以下要素缺一不可报告要素说明受影响的包或功能page-agent、page-agent-ext浏览器扩展、page-agent/core、page-agent/llms等工作区包或某一具体功能模块如页面控制、标签页控制、Hub 通信精确的版本、commit 或构建例如 npm 包版本号、main分支 commit hash、扩展构建产物标识浏览器、操作系统与运行时环境Chrome/Edge 版本、操作系统、扩展运行环境side panel、hub 页面等复现步骤或概念验证PoC从触发到影响的最小复现路径尽量附带可执行的 PoC预期影响明确描述漏洞可能导致的后果数据泄露、越权执行、约束绕过等对照仓库实现上述受影响的包或功能可以在以下位置定位到可复现入口页面内 GUI 代理核心page-agent/core入口见 PageAgentCore.ts浏览器扩展side panel / hub / 后台packages/extension/src/entrypoints 目录下的background.ts、content.ts、sidepanel、hub等页面控制器DOM 分析、遮罩、页面信息提取packages/page-controller/src/PageController.tsLLM 客户端API 调用、错误处理packages/llms/src/OpenAIClient.ts。在复现步骤中标注涉及的具体文件与调用链可以显著降低维护者的排查成本也便于评审者核对影响面。三、安全边界Scope什么算真实的安全缺陷这是整份策略中最具技术含量的部分。官方优先处置**真正突破安全边界security boundary failure**的报告包括三类对数据、令牌或扩展能力的越权访问Unauthorized access to data, tokens, or extension capabilities绕过显式安全约束Bypassing explicit safety constraints默认行为导致的敏感数据暴露Sensitive data exposure caused by default behavior。这三类边界在仓库源码中均有对应的防御实现理解它们有助于判断一个发现是否处于官方关心的范围内。3.1 数据与令牌保护BYOK 本地存储 令牌隔离项目采用Bring Your Own KeyBYOK纯客户端架构隐私条款在 docs/terms-and-privacy.md 中明确软件本身不包含任何后端服务不主动收集或传输用户数据所有数据传输只发生在你的浏览器与你自己配置的 LLM 服务商之间。关键实现证据配置本地存储扩展的 API 地址、API Key、模型选择等配置通过chrome.storage.local保存在本机不进行云端同步、不含任何统计埋点见 docs/terms-and-privacy.md 第 3 节用户令牌生成后台脚本在首次启动时通过crypto.randomUUID()生成PageAgentExtUserAuthToken并存入chrome.storage.local见 background.ts。由于这是隔离世界isolated world中生成的随机值普通页面脚本无法直接读取构成第一道隔离令牌比对才暴露能力内容脚本只有在页面localStorage中的PageAgentExtUserAuthToken与扩展侧令牌一致时才向页面注入并暴露 agent API见 content.ts。也就是说页面必须主动持有匹配令牌才能调用扩展的 agent 能力否则扩展的 GUI 控制能力对任意网页默认不可见。这一点直接对应官方优先级中的对令牌或扩展能力的越权访问——攻击者若能在其他页面窃取/伪造令牌即构成此类越权。3.2 显式安全约束提示词规则与页面侧 API 校验绕过显式安全约束对应的第一道防线是 Agent 的系统提示词。在 system_prompt.md 中可以找到多条显式安全规则例如不主动登录Dont login into a page if you dont have to. Dont login if you dont have the credentials.没有凭据时不得登录验证码人工接管遇到验证码时停止任务并请用户处理而不是尝试破解受限执行只能操作带有数字索引的可交互元素不得重复无进展动作任务无法继续时必须调用done终止。第二道防线在页面侧 API 的入参校验main-world.ts暴露的execute()会对task、config的完整性做运行时校验task 必须为非空字符串、baseURL/model必填并在扩展侧对agent 正在运行做单例互斥见 content.ts防止并发任务互相干扰或抢占执行通道。第三道防线是数据脱敏钩子官方文档页>我的版本是main或最新 npm 发布版吗不是就先升级再报告我是否通过私有报告通道而非公开 issue/PR提交报告中是否包含受影响的包/功能、精确版本或 commit、浏览器/OS/运行时、复现步骤或 PoC、预期影响该问题是否属于用户自定义集成忽略了文档化防护或客户端构建内嵌密钥这类默认范围之外的情况我是否遵守了修复发布前不公开披露的政策相关文档与源码索引官方安全策略原文docs/SECURITY.md隐私与使用条款BYOK、数据流向、存储方式docs/terms-and-privacy.md扩展权限与 manifest 配置wxt.config.js后台令牌生成与消息代理background.ts内容脚本令牌匹配与 agent 暴露content.ts页面侧 API 入口与入参校验main-world.tsAgent 显式安全规则系统提示词system_prompt.md数据脱敏钩子示例data-masking/page.tsx元素黑白名单与高危操作控制security-permissions/page.tsx【免费下载链接】page-agentJavaScript in-page GUI agent. Control web interfaces with natural language.项目地址: https://gitcode.com/GitHub_Trending/pa/page-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考