【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载导读pxpipe 是一款通过将文本上下文渲染为图片来降低 Claude Code Token 消耗的本地代理与 Cloudflare Worker。由于它在请求链路上直接持有 API 凭据并可能处理机密 Prompt 与工具结果其安全设计直接决定部署是否安全。本文以仓库 SECURITY.md 与 docs/SECURITY_MODEL.md 为骨架结合 src/worker.ts、src/node.ts、src/core/proxy.ts 与对应测试完整讲解漏洞报告流程、Node/Worker 两种部署形态的安全基线、凭据路由策略、请求体大小边界以及部署者应遵循的威胁模型与安全审查清单。读完本文你将能安全地把 pxpipe 部署为本机代理或公开 Worker并知道在改动路由、日志、依赖时该检查哪些安全点。支持版本与漏洞报告流程pxpipe 遵循最新版本优先修复的安全策略。官方明确说明安全修复只应用于最新发布的版本用户在报告一个可能已被修复的问题之前应先升级到最新 release。这意味着持续跟进版本发布是安全使用的前提。漏洞报告方面项目划出了几条硬性红线不要为疑似漏洞开公开 Issue也不要在任何公开讨论中附带 secrets、Prompt、日志、请求体或 PoC 利用代码应通过 GitHub 的private vulnerability reportingSecurity Advisories表单私下提交报告中尽量包含以下信息来自 SECURITY.md 原文要求受影响版本与运行时Node 还是 Cloudflare Workers复现所需的部署配置务必移除 secrets安全影响与谁可以触发最小复现步骤或 PoC任何建议的缓解措施。维护者收到报告后的处理流程为确认报告 → 评估严重性 → 协调修复与发布 → 在匿名要求之外为报告者署名。官方同时要求报告者给补丁留出时间再公开细节。部署安全基线两种运行时的不同边界pxpipe 的部署形态决定了它的暴露面。仓库在 SECURITY.md 中给出了两条明确的部署准则docs/SECURITY_MODEL.md 又以威胁模型形式把它们固化下来。Node 服务端默认 loopback非回环绑定必须前置认证反向代理Node 版服务端默认只监听127.0.0.1。在 src/node.ts 中可以看到默认值即 loopbackhost: process.env.HOST?.trim() || 127.0.0.1,从源码注释可以确认这样设计的原因默认回环监听只对可信的本机用户可达一旦通过HOST显式改为非回环地址就意味着操作者必须自行在代理 API 前提供认证与 TLS否则任何能触达该端口的人都能调用代理 API、消耗配置的 API 配额。需要特别强调的是dashboard 路由始终保持 loopback-only。也就是说即使HOST被改为非回环地址暴露到网络上的也只有代理 APItelemetry 与捕获到的上下文数据所在的面板路由不会被带出去。这一点在 src/node.ts 的接口注释中明确写出非回环绑定暴露的only the proxy API because dashboard routes remain loopback-only。Cloudflare Worker凭据注入时必须配置共享密钥缺省即失败关闭Worker 部署是默认公网可达的workers.devURL 可被发现因此它采用的是共享密钥认证 fail-closed失败关闭的模型。核心规则是只要部署中注入了任何 provider 凭据ANTHROPIC_API_KEY、OPENAI_API_KEY、CLOUDFLARE_API_TOKEN就必须同时配置PXPIPE_WORKER_SECRET未配置时 Worker 直接拒绝服务503而不是降级为开放代理。这一逻辑在 src/worker.ts 中有完整的实现if (env.ANTHROPIC_API_KEY || env.OPENAI_API_KEY || env.CLOUDFLARE_API_TOKEN) { if (!env.PXPIPE_WORKER_SECRET) { return new Response(JSON.stringify({ error: refusing to proxy: ... }), { status: 503, ... }); } const presented req.headers.get(x-pxpipe-secret) ?? ; if (!(await secretsMatch(presented, env.PXPIPE_WORKER_SECRET))) { return new Response(JSON.stringify({ error: missing or invalid x-pxpipe-secret header }), { status: 401, ... }); } }配置方式与调用方式来自 src/worker.ts 源码注释设置密钥npx wrangler secret put PXPIPE_WORKER_SECRET调用方需在每个请求头中携带x-pxpipe-secret: 密钥值。secretsMatch的实现还透露了一个细节比较的是SHA-256 摘要而非原始字符串见 src/worker.ts逐字节异或累加后判断是否全零从而避免前缀匹配带来的时间侧信道。这是共享密钥认证在实现层的标准加固也是威胁模型中保持 fail-closed 检查与恒定工作量比较测试这条贡献者要求对应的源码。诊断捕获开关PXPIPE_DEBUG_CAPTURE_4XX严禁在生产开启pxpipe 支持将 4xx 请求体与上游错误体持久化到磁盘以辅助调试但这一能力默认关闭、显式开启。在 src/node.ts 中captureErrorReqBody: process.env.PXPIPE_DEBUG_CAPTURE_4XX 1,开关开启后的实际行为在启动日志中有明确警告src/node.tsPXPIPE_DEBUG_CAPTURE_4XX1 — persisting full 4xx request and upstream error bodies (prompts any secrets in context) to ... Debugging only.捕获的 4xx 请求体可能完整包含 Prompt 甚至凭据而自定义网关的上游错误体也可能回显 Prompt 片段或凭据src/node.ts 的日志逻辑对此有专门注释。因此官方要求生产环境禁止开启仅限本地调试。本地产物的 POSIX 权限保护telemetry、诊断捕获、渲染出的 PNG、配置文件与导出产物在 POSIX 系统上全部使用 owner-only 权限。这在 src/node.ts 的配置持久化代码中有直接体现fs.mkdirSync(path.dirname(file), { recursive: true, mode: 0o700 }); fs.writeFileSync(tmp, ${JSON.stringify(cfg, null, 2)}\n, { mode: 0o600 }); fs.renameSync(tmp, file); fs.chmodSync(file, 0o600);目录0o700、文件0o600并且采用先写临时文件再 rename的方式避免写入中途崩溃导致配置损坏。这印证了威胁模型中本地工件 owner-only这一控制项的落地方式。请求体大小边界在分配内存之前拒绝超限请求威胁模型中有一条与内存耗尽相关的控制可转换路由transformable routes在分配内存之前就拒绝超过maxRequestBytes的请求体默认上限 16 MiB对应环境变量PXPIPE_MAX_REQUEST_BYTES。相关常量定义在 src/core/proxy.tsexport const DEFAULT_MAX_REQUEST_BYTES 16 20; // 16 MiB这里有两个实现要点值得部署者了解使用流式读取的实际字节数而不是声明的content-length。src/core/proxy.ts 的readBodyBounded说明注释指出声明的content-length只作为不读一个字节就直接拒绝的快捷方式它永远不是权威值——chunked 发送方可能省略它而一个谎报长度的发送方代价为零真正执行上限的是流式循环本身所以谎报大小的请求体与诚实声明的一样被同一数字封顶。这正是威胁模型中使用流式大小而非声明大小这一控制的具体实现。超限即返回 provider 形态的 413且不做任何上游调用。在 src/core/proxy.ts 附近请求体读取被放在任何调用方可控分配之前、任何上游调用之前const bounded await readBodyBounded(req, maxRequestBytes); if (!bounded.ok) { const message request body exceeds the ${maxRequestBytes}-byte pxpipe limit (${bounded.declaredBytes ! undefined ? declared ${bounded.declaredBytes}, : } read ${bounded.observedBytes}); // ... 返回 413 }值得注意的例外仅做标签label-only的路由不会被此上限拒绝——它们承载上传与音频但其模型嗅探model sniff同样有界见 src/core/proxy.ts 的maxRequestBytes注释。在 Node 端坏值非正整数字节数的处理是直接退出进程而非忽略src/node.tsprocess.exit(2)并打印错误信息因为一个不可用的上限绝不能静默变成没有上限。而 Worker 端无法像 Node 那样对坏配置退出因此在 src/worker.ts 中positiveInt对非法值返回undefined核心默认值16 MiB继续生效——这也符合坏值必须回落到默认值而非变成无上限的一致原则。凭据路由策略凭据按形状分类绝不跨 provider 泄漏威胁模型中另一条关键控制是provider 凭据绝不能路由到错误的上游。pxpipe 的实现不读取任何本地 token 存储而是只按请求头形状分类入站凭据src/core/proxy.ts入站凭据类型判定依据none无authorization与x-api-keyanthropic-key仅x-api-key头Anthropic 使用anthropic-bearerBearer sk-ant-…Anthropic key 或订阅 tokenoauth-jwtBearer JWTCodex / ChatGPT 订阅认证的形态api-key-bearerBearer sk-…但非 AnthropicOpenAI 风格opaque-bearer未识别形状的 bearer网关 / 自托管上游分类只观察前缀与段结构从不读取凭据内容本身测试 tests/credential-route-policy.test.ts 用结构化用例验证了这一点包括Anthropic bearer 与x-api-key并存时bearer 是更强的信号这一边界。分类之后resolveOpenAIRouteAuthsrc/core/proxy.ts按三条规则决定放行行为Anthropic 形态凭据永不跨越 provider无论 host 是否配置了 keyAnthropic-shaped 凭据在 OpenAI 路由上要么被替换host 有 key要么被丢弃host 无 key理由是anthropic-credential-never-crosses-providers——否则 Anthropic 密钥会被直接转发给 OpenAI属于凭据泄漏 必然 401订阅 OAuth 属于调用者优先于 host 配置的 keyoauth-jwt一律keep-inbound。原因很实际Codex 用户经由 pxpipe 代理时本意是花自己的订阅额度静默替换成 host key 会记错账单且通常失败、用户无从察觉src/core/proxy.ts普通 keyhost 配置了 key 则替换否则透传——这就是文档化的host 供给凭据模式。这一矩阵被 tests/credential-route-policy.test.ts 以 13 个组合全覆盖测试含无 key 配置时绝不返回 replace、每个决策都带有可解释的 reason并在该文件头注释中点明策略表是契约每新增路由或 provider 都只能扩展策略表而非调用点。威胁模型资产、信任边界与残余风险docs/SECURITY_MODEL.md 是一份活的威胁模型官方明确声明它不是软件无漏洞的声明。其中值得部署者逐条对照的内容包括资产清单请求头或部署配置中的 provider 凭据Prompt、system message、工具 schema 与工具结果内容由这些内容派生出的渲染 PNG、导出包与 factsheet本地事件日志、可选的诊断请求体与会话元数据绑定在配置凭据上的 provider 配额与账单npm 包及其发布来源release provenance。信任边界图示client - Node proxy or Worker - configured provider/gateway | - transforms and rendered context - local logs/dashboard (Node) or Workers Logs maintainer - GitHub Actions - npm trusted publishingclient→proxy 与 proxy→provider 两跳跨越网络信任边界Node dashboard 因暴露 telemetry 与捕获上下文而跨越另一条边界依赖安装与发布则跨越软件供应链边界。安全假设部署者必须满足的前提Node 进程以非特权用户运行在可信机器上默认127.0.0.1监听仅对可信本机用户可达操作者将HOST设为非回环地址时自行在代理 API 前提供认证与 TLSdashboard 路由保持 loopback-only上游 URL 与网关头是可信操作者配置而非攻击者可控的请求输入能读 pxpipe 日志目录或 Workers Logs 的人可能获知敏感元数据诊断体捕获按秘密材料对待知道PXPIPE_WORKER_SECRET的调用方被授权消费该 Worker 部署中配置的凭据。威胁与控制对照表核心条目威胁现有控制贡献者要求公网部署消耗配置的 API keyWorker 要求PXPIPE_WORKER_SECRET且 fail-closed保留 fail-closed 检查与恒定工作量比较测试provider 凭据路由到错误上游显式入站凭据路由策略resolveOpenAIRouteAuthAnthropic 形态永不达 OpenAI、订阅 OAuth 保留不替换、host key 只替换普通 key按头形状分类不读本地 token 存储每新增路由/provider 扩展策略表而非调用点保持完整矩阵有测试Prompt 或密钥经 telemetry 泄漏完整 4xx 体捕获为 opt-in正常事件只保留哈希/元数据本地工件 owner-only不要向日志添加原始内容新增持久化必须文档化dashboard 暴露捕获上下文dashboard 路由要求 loopback 源与 host拒绝跨站突变每个 dashboard 路由都按敏感对待保留两项检查超大 dashboard 请求耗尽内存dashboard 请求体有界保持解析前设界新端点补负向测试超大 proxy 请求耗尽内存可转换路由在分配前按PXPIPE_MAX_REQUEST_BYTES默认 16 MiB拒绝用流式大小而非声明大小label-only 路由给模型嗅探设界在证明未超限前绝不把入站体读完新路由补精确边界/缺失长度/谎报长度测试恶意依赖或受损发布冻结 lockfile、三天发布年龄门禁、受限生命周期脚本、OIDC 可信发布、provenance保持最小权限工作流权限审查 lockfile/生命周期变更存在漏洞的依赖未移除Dependabot、CodeQL/GitHub 安全扫描、高危 CI 审计门禁、针对性 overrides运行pnpm audit直接依赖采用修复范围后移除 overrides范围外与残余风险部署者须知pxpipe不对 Node 服务端或 dashboard 做认证非回环部署若无认证反向代理按设计就是不安全的pxpipe 无法保护内容到达配置的 provider、网关、日志接收端或可访问其文件的本地用户之后的安全一个恶意的可信操作者可以配置一个接收请求凭据与内容的上游——上游配置绝不能暴露给不可信调用方共享密钥认证不提供按用户身份、撤销、限流或授权范围面向公网的部署应在边缘补充这些控制。安全审查清单改动路由、日志、依赖前的 7 个问题对路由、头、日志、持久化、dashboard 端点、认证、依赖或发布工作流的任何改动都应回答 docs/SECURITY_MODEL.md 中的 7 个问题凭据会不会流入错误的 provider、响应或日志原始 Prompt 或工具内容会不会被意外持久化或展示未认证调用者是否会获得新的操作或资源消耗路径请求大小与攻击者可控的集合是否在任何工作开始前就设界改动是否引入新的上游、重定向或 SSRF 路径是否扩大了 GitHub Actions 权限或执行了新的安装脚本失败模式是否 fail-closed并且是否由回归测试覆盖这套清单同时是贡献者视角的契约例如凭据路由的策略表、请求体边界测试、dashboard 双重检查均有对应的源码与测试锚点tests/credential-route-policy.test.ts、src/core/proxy.ts、src/worker.ts。部署加固速查表综合 SECURITY.md 与源码给出可落地的加固清单部署形态必做项对应依据Node本机保持默认127.0.0.1监听若设HOST为非回环前置认证 TLS 反向代理dashboard 天然 loopback-onlysrc/node.tsNode任意生产环境不设PXPIPE_DEBUG_CAPTURE_4XX1日志目录与导出产物保持 owner-only0o700/0o600src/node.ts、src/node.tsNode任意按需调整PXPIPE_MAX_REQUEST_BYTES默认 16 MiB坏值会导致进程退出而非无上限src/core/proxy.ts、src/node.tsWorker注入任何 provider 凭据时必须npx wrangler secret put PXPIPE_WORKER_SECRET调用方携带x-pxpipe-secret头未配置即 503 fail-closedsrc/worker.ts供应链冻结 lockfile、审查生命周期脚本、pnpm audit、跟踪 Dependabot/CodeQL 告警移除不再需要的 overridesdocs/SECURITY_MODEL.md 威胁表结论pxpipe 的安全设计的核心可以概括为三句话本机部署默认回环、公网部署 fail-closed、凭据按形状分类路由且绝不跨 provider。它把谁能花我的钱凭据消费与谁能读我的上下文Prompt 与工具结果持久化作为两条主线以共享密钥、请求体字节级上限、loopback-only dashboard 与 owner-only 文件权限等控制组合落地。对部署者而言最需要记住的是两条非回环 Node 部署必须前置认证反代Worker 注入凭据必须配PXPIPE_WORKER_SECRET对开发者而言任何路由与日志改动都应先过一遍安全审查清单再补上对应的回归测试。完整的信任边界、假设与残余风险请以 docs/SECURITY_MODEL.md 为准它才是那份活的威胁模型。赞分享【免费下载链接】pxpipecut Claude Code token usage by rendering text context as images项目地址https://gitcode.com/gh_mirrors/px/pxpipe点击查看免费下载相关推荐Zeek 安全策略与安全模型漏洞报告流程、信任边界与部署加固实践Zeek 安全策略与安全模型漏洞报告流程、信任边界与部署加固实践 本文以 Zeek 仓库中的 SECURITY.md https://link.gitcode网络安全网络IDSEverOS 安全指南威胁模型、漏洞上报流程与本地优先部署加固实践EverOS 安全指南威胁模型、漏洞上报流程与本地优先部署加固实践 EverOS 是一款面向 AI Agent 的本地优先local first记忆层记人工智能AI AgentAgent 记忆RAGBeadsbd安全指南漏洞报告流程、数据保护边界与本地优先安全模型Beadsbd安全指南漏洞报告流程、数据保护边界与本地优先安全模型 导读 BeadsCLI 命令为 bd 是一款面向编码 Agent 的本地优先问题AI 应用Agent 记忆CLIMCP 服务项目管理人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考