尧图网页设计 
LobeHub deep-review 安全维度注入、越权与泄密审查规则全解析【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub本篇以 LobeHub 仓库中 deep-review 技能的安全维度规则文件 security.md 为主体逐条拆解其检查清单、违规判定与豁免机制并结合仓库中的真实防御实现如 packages/ssrf-safe-fetch说明每条规则背后对应的代码事实。读完你能掌握如何在 LobeHub 这类「Next.js TRPC Drizzle」的多端架构中对一次 diff 做注入、授权绕过与敏感信息泄漏三类安全审查以及为什么安全维度在整个评审体系里享有不受代码库惯例校准约束的特殊地位。1. 安全维度在 deep-review 技能中的定位deep-review 是 LobeHub 仓库内置的多维度代码评审技能SKILL.md每个评审维度对应references/dimensions/下的一份独立规则文件light 模式只读该文件的 Quick checklistdeep 模式则要求评审子代理通读全文件并跟随其路由表读取规则来源。安全维度在技能维度表中的登记如下id 前缀为sec即该维度产出的每条发现finding编号形如sec-1、sec-2覆盖范围为 injection, auth bypass, secret/PII leakage, business-slot confidentialityVerified? 一列为yes意味着它的安全发现必须经过独立的 verify 子代理逐条证伪而不是直接进报告。仓库根的 AGENTS.md 在 Code Review 一节明确要求评审 PR / diff / 分支前必须先读 deep-review 技能普通评审请求走 light 模式一个独立评审者对照各维度 Quick checklist完整多子代理 deep 模式仅在显式调用时运行。这正是本文规则文件的生效入口。1.1 关键设计安全维度豁免代码库校准deep-review 的核心原则第 4 条是按代码库现状校准——如果某种写法在存量代码中普遍存在、且本次 diff 没有使其恶化就不算发现。但 SKILL.md 在同一原则末尾特别标注(Security is exempt from all calibration — see the dimension file.)安全维度被整体豁免。这条豁免在两处模板中落地评审子代理提示词 review-prompt.md 的 Calibration 小节写明维度文件可声明calibration_exempt: true例如 security声明后无论是否有先例都要上报report regardless of precedent验证子代理提示词 verify-prompt.md 的第 9 步要求对代码库与生命周期校准逐条应用但除非维度声明了calibration_exempt: true——也就是说验证环节也不能以别处早就这么写了为由把安全问题判为误报。对应地安全维度文件自身的 frontmatter 就声明了这一点--- id_prefix: sec verify: true skip_when: lockfile/generated-only diff (docs, i18n copy, comments are leak vectors — never skip for text changes) calibration_exempt: true ---其正文开宗明义This dimension is exempt from the codebase-calibration principle: a vulnerability is a finding even if the same weakness exists elsewhere in the repo, and severity is never downgraded for precedent.漏洞就是发现即使同样的弱点在仓库别处已经存在严重性永不因先例而降级。这与 SKILL.md 维度表中 security 行Verified? yes的设定互为表里——安全发现既独立于先例又必须经过独立验证。1.2 什么时候可以跳过安全维度pruning 表的唯一豁免条件SKILL.md 的裁剪表Pruning table规定了每个维度的跳过条件security 一行是仅在lockfile/generated-only diff时跳过而文档、i18n 文案变更仍然要跑安全维度——因为文本本身就是泄漏向量密钥、内部 URL、商业细节。frontmatter 里的skip_when字段docs, i18n copy, comments are leak vectors — never skip for text changes是这一规则在维度文件内的镜像。这个设计针对的是 LobeHub 这类 i18n 密集型仓库的现实风险18 个语言目录locales/ar/…locales/zh-TW/每个含 50 命名空间 JSON 文件中的文案改动完全可能把 API 密钥、内网地址或商业逻辑细节写进提交历史。2. Quick checklist八条注入/授权/泄漏检查项逐条解析Quick checklist 是 light 模式评审者必须完整读取的部分含嵌套示例小节也是 deep 模式的骨架。原文共八条这里逐条展开其在本仓库技术栈下的具体含义。仓库的技术底座见 AGENTS.md Tech Stack是 Next.js 16 React 19 TypeScript、TRPC 类型安全后端、Drizzle ORM PostgreSQL、SWR 数据获取——这决定了每条检查项的实际落点。2.1 注入Injectionuser input reaching SQL (rawsqlfragments), shell commands,dangerouslySetInnerHTML, path construction本仓库数据访问层是 Drizzle ORMpackages/database/常规查询走参数化检查项特意点名原始sql模板片段因为 Drizzle 允许sql模板标签拼接用户输入一旦未参数化即成 SQL 注入面。另外三类 sink 分别是shell 命令拼接后端apps/server/与 Electron 桌面端apps/desktop/都存在进程与脚本调用场景、React 的dangerouslySetInnerHTML富文本渲染路径、以及路径构造文件上传、知识库文件加载等会拼接磁盘路径。2.2 授权Authorization以邻居实现为标尺new TRPC procedures / API routes missing the auth middleware their siblings use; queries missing user-scoping (userIdfilter) that sibling queries apply这条规则的执行方法写死在How to check第 2 步打开同一 router 下两个相邻的 procedure对比它们的中件件与用户范围过滤。在 TRPC 架构下缺鉴权不是一个孤立事实而是一个相对事实——同路由兄弟 procedure 都挂了鉴权中间件、新 procedure 没挂或者兄弟查询都带userId过滤、新查询没带才构成发现。这把主观的这里好像没鉴权变成了可执行的对比检查。2.3 敏感数据进日志Sensitive data in logs: API keys, tokens, credentials, full request bodies inconsole.*/debug()output No base64 blobs printed to terminal output (freezes output, may embed secrets)两条针对日志面API 密钥、令牌、凭证、完整请求体出现在console.*/debug()输出中以及终端输出中打印 base64 大 blob——后者既会卡死输出还可能间接嵌入密钥。在 CLI 应用apps/cli/和开发脚本尤其值得盯。2.4 硬编码密钥与NEXT_PUBLIC_*暴露面Hardcoded secrets — must come from environment variables New env vars holding secrets must not be exposed client-side (NEXT_PUBLIC_*review)密钥必须来自环境变量新增的、承载密钥的环境变量不得以NEXT_PUBLIC_前缀暴露到客户端包中。检查项明确要求对NEXT_PUBLIC_*做专门复核。2.5 SSRFSSRF: user-controlled URLs fetched server-side without allowlisting服务端抓取用户可控 URL 且没有白名单防护是 SSRF 检查项。本仓库对此有现成的基础设施见第 5 节packages/ssrf-safe-fetch。2.6 业务槽位保密Business-slot confidentialitysrc/business/andpackages/business/must not expose commercial logic, pricing, or private infrastructure details in code or comments — slots export only minimal generic contracts and safe defaults这是 LobeHub 特有的规则src/business/与packages/business/两个目录在本仓库中真实存在是业务槽位开源侧只允许导出最小化的通用契约和安全默认值不得在代码或注释中暴露商业逻辑、定价、私有基础设施细节。它把开源仓库里什么不该出现这一通常靠自觉的约束变成了一条可检查的清单条目并配套了专门的操作方法见 3.2 第 4 步像外部贡献者一样读这些文件的 diff。3. 规则来源与检查流程3.1 Rule sources维度文件声明了 deep 模式评审者在开始评审前必须读的规则来源仓库根 AGENTS.md 的 security 相关章节业务槽位、密钥文件diff 所新增内容的邻居实现——相邻 procedure 的鉴权模式是判定缺失鉴权的标尺。3.2 How to check四步执行法维度文件给出的操作流程可直接照搬执行追源到汇trace to sinks把每个新增外部输入请求参数、用户内容、webhook 载荷、env一路追到它的 sink寻找未转义/未校验的跳板对比兄弟实现对每个新 procedure/路由打开同一 router 下两个相邻实现对比中间件与用户范围过滤模式搜索在 diff 上用rg搜console.、debug(、NEXT_PUBLIC_、dangerouslySetInnerHTML、原始sql模板用法——这五个模式正是 2.1–2.4 检查项的可机器化特征业务槽位外审视角读src/business//packages/business/的 diff 时像外部贡献者一样问一句——任何名称、注释、常量是否在泄露私有商业行为3.3 Violations 与 Not violations判定的对称规则构成违规Violations快速清单中任何一条且可被攻击者触达或在开源仓库中可见鉴权/范围过滤弱于既有的兄弟实现模式。不构成违规Not violations——这部分同样重要防止评审过度报警输入在上游已被完全约束例如在边界处校验过的 enum——但必须先验证该约束存在再排除并在报告中引用它cite it密钥存放在仅本地、且被 gitignore 的文件中引用其文件名本来就是它的职责——但必须确认该文件确实被 gitignore。这种违规/非违规对称书写配合verify: true构成了 deep-review 反幻觉设计的一部分评审者负责带证据上报独立 verify 子代理负责先找反例上游保证、提前返回、框架行为、既有校验再下confirmed/false_positive/need_more_context三态裁决且每个确认结论必须有 file-and-line 证据。对安全类发现verify 提示词中blocks_release的定义把 security/auth failure 明确列入必须阻塞发布一类verify-prompt.md。4. 两种评审模式下安全维度的加载方式差异模式触发安全维度做什么Light默认任何普通评审请求review this PR、贴 diff 让你看问题一个独立评审者完整读取本文件的Quick checklist含嵌套示例小节裁剪表同样适用——仅 lockfile/generated-only diff 不跑安全项Deep显式调用/deep-review、run deep review评审子代理通读本文件全量再按Rule sources一节读取 AGENTS.md 相关章节与邻居实现发现进入按维度流水线的独立 verify 环节安全维度因calibration_exempt: true在校准时不做先例降级值得注意的是裁剪表对docs-only的界定面向人类的纯散文才算文档而.agents/skills/**、AGENTS.md/CLAUDE.md、prompt 模板这类写给 agent 的可执行指令在裁剪意义上等同于代码——它们的散文承载控制流与契约。因此一份修改了 agent 指令文件的 diff 永远不会被当作 docs-only 而绕过安全审查。5. 规则与仓库实现的互证以 SSRF 防护为例检查清单里SSRF: user-controlled URLs fetched server-side without allowlisting这条在仓库中有直接的实现级对应物packages/ssrf-safe-fetch。该包为服务端提供一个基于request-filtering-agent的 SSRF-safe fetch其SSRF0ptions接口实际为SSRFOptions见 index.ts#L8-L24定义了三个可配置项export interface SSRFOptions { /** List of IP addresses to allow */ allowIPAddressList?: string[]; /** Whether to allow private/local IP addresses */ allowPrivateIPAddress?: boolean; /** * Maximum response body size in bytes. ... Use this for any fetch that * downloads untrusted content (e.g. web crawlers) ... */ maxContentLength?: number; }allowIPAddressList/allowPrivateIPAddress正是清单中allowlisting要求的服务端落点默认拒绝私网/本地 IP显式白名单才可放行maxContentLength配合readBodyWithCap对响应体做软截断读满上限即中止流并释放连接防止抓取不可信内容时无界缓冲撑爆内存——这是 SSRF/抓取链路上资源耗尽的配套防护同目录的 index.test.ts 提供了该行为可回归测试的依据。也就是说当 deep-review 安全维度审到新增一个服务端抓取用户 URL的 diff 时兄弟实现标尺Rule sources 第 2 条会指向这类既有防护新代码若直接fetch(url)而不经过带白名单与截断的受控 fetch就构成弱于既有兄弟模式的违规。同理清单中的 TRPC 鉴权对比、原始sql模板检查分别以apps/server/中既有的 router 模式和packages/database/的 Drizzle 用法为校准基线——安全项虽豁免先例降级但用什么做标尺依然来自仓库内真实实现。6. 实战要点小结写 diff 时新增外部输入先想 sinkSQL 模板、shell、dangerouslySetInnerHTML、路径拼接新增 TRPC procedure 对照同 router 邻居补鉴权中间件与userId范围过滤密钥只进环境变量且永远不挂NEXT_PUBLIC_前缀服务端抓用户 URL 走packages/ssrf-safe-fetch这类带白名单的受控入口src/business/与packages/business/里不写商业逻辑、定价与私有基础设施细节。做 i18n/文案变更时不要以为只是文本——文档、文案、注释同样是泄漏向量安全维度对纯文本变更照常运行这是skip_when字段唯一收窄到 lockfile/generated-only 的原因。评审时light 模式完整读 Quick checklistdeep 模式先读 AGENTS.md 安全相关章节与邻居实现按四步流程执行并用rg的五个模式词兜底记住豁免规则的方向性——存量代码里也有同样弱点不是安全问题的减分项而上游已约束输入才是合法的非违规理由且必须引用约束出处。安全维度文件虽短但它把一个 LobeHub 式的多端 AI 产品Web、Electron 桌面端、CLI、Hono 后端服务见 AGENTS.md 项目结构一节中最常见的三类事故——注入、越权、泄漏——压缩成了可执行、可验证、可豁免判定的规则集并通过calibration_exempt与verify: true的组合确保这些发现在整条评审流水线中既不被先例稀释、也不被模型臆断。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LobeHub deep-review 安全维度：注入、越权与泄密审查规则全解析
LobeHub deep-review 安全维度注入、越权与泄密审查规则全解析【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub本篇以 LobeHub 仓库中 deep-review 技能的安全维度规则文件 security.md 为主体逐条拆解其检查清单、违规判定与豁免机制并结合仓库中的真实防御实现如 packages/ssrf-safe-fetch说明每条规则背后对应的代码事实。读完你能掌握如何在 LobeHub 这类「Next.js TRPC Drizzle」的多端架构中对一次 diff 做注入、授权绕过与敏感信息泄漏三类安全审查以及为什么安全维度在整个评审体系里享有不受代码库惯例校准约束的特殊地位。1. 安全维度在 deep-review 技能中的定位deep-review 是 LobeHub 仓库内置的多维度代码评审技能SKILL.md每个评审维度对应references/dimensions/下的一份独立规则文件light 模式只读该文件的 Quick checklistdeep 模式则要求评审子代理通读全文件并跟随其路由表读取规则来源。安全维度在技能维度表中的登记如下id 前缀为sec即该维度产出的每条发现finding编号形如sec-1、sec-2覆盖范围为 injection, auth bypass, secret/PII leakage, business-slot confidentialityVerified? 一列为yes意味着它的安全发现必须经过独立的 verify 子代理逐条证伪而不是直接进报告。仓库根的 AGENTS.md 在 Code Review 一节明确要求评审 PR / diff / 分支前必须先读 deep-review 技能普通评审请求走 light 模式一个独立评审者对照各维度 Quick checklist完整多子代理 deep 模式仅在显式调用时运行。这正是本文规则文件的生效入口。1.1 关键设计安全维度豁免代码库校准deep-review 的核心原则第 4 条是按代码库现状校准——如果某种写法在存量代码中普遍存在、且本次 diff 没有使其恶化就不算发现。但 SKILL.md 在同一原则末尾特别标注(Security is exempt from all calibration — see the dimension file.)安全维度被整体豁免。这条豁免在两处模板中落地评审子代理提示词 review-prompt.md 的 Calibration 小节写明维度文件可声明calibration_exempt: true例如 security声明后无论是否有先例都要上报report regardless of precedent验证子代理提示词 verify-prompt.md 的第 9 步要求对代码库与生命周期校准逐条应用但除非维度声明了calibration_exempt: true——也就是说验证环节也不能以别处早就这么写了为由把安全问题判为误报。对应地安全维度文件自身的 frontmatter 就声明了这一点--- id_prefix: sec verify: true skip_when: lockfile/generated-only diff (docs, i18n copy, comments are leak vectors — never skip for text changes) calibration_exempt: true ---其正文开宗明义This dimension is exempt from the codebase-calibration principle: a vulnerability is a finding even if the same weakness exists elsewhere in the repo, and severity is never downgraded for precedent.漏洞就是发现即使同样的弱点在仓库别处已经存在严重性永不因先例而降级。这与 SKILL.md 维度表中 security 行Verified? yes的设定互为表里——安全发现既独立于先例又必须经过独立验证。1.2 什么时候可以跳过安全维度pruning 表的唯一豁免条件SKILL.md 的裁剪表Pruning table规定了每个维度的跳过条件security 一行是仅在lockfile/generated-only diff时跳过而文档、i18n 文案变更仍然要跑安全维度——因为文本本身就是泄漏向量密钥、内部 URL、商业细节。frontmatter 里的skip_when字段docs, i18n copy, comments are leak vectors — never skip for text changes是这一规则在维度文件内的镜像。这个设计针对的是 LobeHub 这类 i18n 密集型仓库的现实风险18 个语言目录locales/ar/…locales/zh-TW/每个含 50 命名空间 JSON 文件中的文案改动完全可能把 API 密钥、内网地址或商业逻辑细节写进提交历史。2. Quick checklist八条注入/授权/泄漏检查项逐条解析Quick checklist 是 light 模式评审者必须完整读取的部分含嵌套示例小节也是 deep 模式的骨架。原文共八条这里逐条展开其在本仓库技术栈下的具体含义。仓库的技术底座见 AGENTS.md Tech Stack是 Next.js 16 React 19 TypeScript、TRPC 类型安全后端、Drizzle ORM PostgreSQL、SWR 数据获取——这决定了每条检查项的实际落点。2.1 注入Injectionuser input reaching SQL (rawsqlfragments), shell commands,dangerouslySetInnerHTML, path construction本仓库数据访问层是 Drizzle ORMpackages/database/常规查询走参数化检查项特意点名原始sql模板片段因为 Drizzle 允许sql模板标签拼接用户输入一旦未参数化即成 SQL 注入面。另外三类 sink 分别是shell 命令拼接后端apps/server/与 Electron 桌面端apps/desktop/都存在进程与脚本调用场景、React 的dangerouslySetInnerHTML富文本渲染路径、以及路径构造文件上传、知识库文件加载等会拼接磁盘路径。2.2 授权Authorization以邻居实现为标尺new TRPC procedures / API routes missing the auth middleware their siblings use; queries missing user-scoping (userIdfilter) that sibling queries apply这条规则的执行方法写死在How to check第 2 步打开同一 router 下两个相邻的 procedure对比它们的中件件与用户范围过滤。在 TRPC 架构下缺鉴权不是一个孤立事实而是一个相对事实——同路由兄弟 procedure 都挂了鉴权中间件、新 procedure 没挂或者兄弟查询都带userId过滤、新查询没带才构成发现。这把主观的这里好像没鉴权变成了可执行的对比检查。2.3 敏感数据进日志Sensitive data in logs: API keys, tokens, credentials, full request bodies inconsole.*/debug()output No base64 blobs printed to terminal output (freezes output, may embed secrets)两条针对日志面API 密钥、令牌、凭证、完整请求体出现在console.*/debug()输出中以及终端输出中打印 base64 大 blob——后者既会卡死输出还可能间接嵌入密钥。在 CLI 应用apps/cli/和开发脚本尤其值得盯。2.4 硬编码密钥与NEXT_PUBLIC_*暴露面Hardcoded secrets — must come from environment variables New env vars holding secrets must not be exposed client-side (NEXT_PUBLIC_*review)密钥必须来自环境变量新增的、承载密钥的环境变量不得以NEXT_PUBLIC_前缀暴露到客户端包中。检查项明确要求对NEXT_PUBLIC_*做专门复核。2.5 SSRFSSRF: user-controlled URLs fetched server-side without allowlisting服务端抓取用户可控 URL 且没有白名单防护是 SSRF 检查项。本仓库对此有现成的基础设施见第 5 节packages/ssrf-safe-fetch。2.6 业务槽位保密Business-slot confidentialitysrc/business/andpackages/business/must not expose commercial logic, pricing, or private infrastructure details in code or comments — slots export only minimal generic contracts and safe defaults这是 LobeHub 特有的规则src/business/与packages/business/两个目录在本仓库中真实存在是业务槽位开源侧只允许导出最小化的通用契约和安全默认值不得在代码或注释中暴露商业逻辑、定价、私有基础设施细节。它把开源仓库里什么不该出现这一通常靠自觉的约束变成了一条可检查的清单条目并配套了专门的操作方法见 3.2 第 4 步像外部贡献者一样读这些文件的 diff。3. 规则来源与检查流程3.1 Rule sources维度文件声明了 deep 模式评审者在开始评审前必须读的规则来源仓库根 AGENTS.md 的 security 相关章节业务槽位、密钥文件diff 所新增内容的邻居实现——相邻 procedure 的鉴权模式是判定缺失鉴权的标尺。3.2 How to check四步执行法维度文件给出的操作流程可直接照搬执行追源到汇trace to sinks把每个新增外部输入请求参数、用户内容、webhook 载荷、env一路追到它的 sink寻找未转义/未校验的跳板对比兄弟实现对每个新 procedure/路由打开同一 router 下两个相邻实现对比中间件与用户范围过滤模式搜索在 diff 上用rg搜console.、debug(、NEXT_PUBLIC_、dangerouslySetInnerHTML、原始sql模板用法——这五个模式正是 2.1–2.4 检查项的可机器化特征业务槽位外审视角读src/business//packages/business/的 diff 时像外部贡献者一样问一句——任何名称、注释、常量是否在泄露私有商业行为3.3 Violations 与 Not violations判定的对称规则构成违规Violations快速清单中任何一条且可被攻击者触达或在开源仓库中可见鉴权/范围过滤弱于既有的兄弟实现模式。不构成违规Not violations——这部分同样重要防止评审过度报警输入在上游已被完全约束例如在边界处校验过的 enum——但必须先验证该约束存在再排除并在报告中引用它cite it密钥存放在仅本地、且被 gitignore 的文件中引用其文件名本来就是它的职责——但必须确认该文件确实被 gitignore。这种违规/非违规对称书写配合verify: true构成了 deep-review 反幻觉设计的一部分评审者负责带证据上报独立 verify 子代理负责先找反例上游保证、提前返回、框架行为、既有校验再下confirmed/false_positive/need_more_context三态裁决且每个确认结论必须有 file-and-line 证据。对安全类发现verify 提示词中blocks_release的定义把 security/auth failure 明确列入必须阻塞发布一类verify-prompt.md。4. 两种评审模式下安全维度的加载方式差异模式触发安全维度做什么Light默认任何普通评审请求review this PR、贴 diff 让你看问题一个独立评审者完整读取本文件的Quick checklist含嵌套示例小节裁剪表同样适用——仅 lockfile/generated-only diff 不跑安全项Deep显式调用/deep-review、run deep review评审子代理通读本文件全量再按Rule sources一节读取 AGENTS.md 相关章节与邻居实现发现进入按维度流水线的独立 verify 环节安全维度因calibration_exempt: true在校准时不做先例降级值得注意的是裁剪表对docs-only的界定面向人类的纯散文才算文档而.agents/skills/**、AGENTS.md/CLAUDE.md、prompt 模板这类写给 agent 的可执行指令在裁剪意义上等同于代码——它们的散文承载控制流与契约。因此一份修改了 agent 指令文件的 diff 永远不会被当作 docs-only 而绕过安全审查。5. 规则与仓库实现的互证以 SSRF 防护为例检查清单里SSRF: user-controlled URLs fetched server-side without allowlisting这条在仓库中有直接的实现级对应物packages/ssrf-safe-fetch。该包为服务端提供一个基于request-filtering-agent的 SSRF-safe fetch其SSRF0ptions接口实际为SSRFOptions见 index.ts#L8-L24定义了三个可配置项export interface SSRFOptions { /** List of IP addresses to allow */ allowIPAddressList?: string[]; /** Whether to allow private/local IP addresses */ allowPrivateIPAddress?: boolean; /** * Maximum response body size in bytes. ... Use this for any fetch that * downloads untrusted content (e.g. web crawlers) ... */ maxContentLength?: number; }allowIPAddressList/allowPrivateIPAddress正是清单中allowlisting要求的服务端落点默认拒绝私网/本地 IP显式白名单才可放行maxContentLength配合readBodyWithCap对响应体做软截断读满上限即中止流并释放连接防止抓取不可信内容时无界缓冲撑爆内存——这是 SSRF/抓取链路上资源耗尽的配套防护同目录的 index.test.ts 提供了该行为可回归测试的依据。也就是说当 deep-review 安全维度审到新增一个服务端抓取用户 URL的 diff 时兄弟实现标尺Rule sources 第 2 条会指向这类既有防护新代码若直接fetch(url)而不经过带白名单与截断的受控 fetch就构成弱于既有兄弟模式的违规。同理清单中的 TRPC 鉴权对比、原始sql模板检查分别以apps/server/中既有的 router 模式和packages/database/的 Drizzle 用法为校准基线——安全项虽豁免先例降级但用什么做标尺依然来自仓库内真实实现。6. 实战要点小结写 diff 时新增外部输入先想 sinkSQL 模板、shell、dangerouslySetInnerHTML、路径拼接新增 TRPC procedure 对照同 router 邻居补鉴权中间件与userId范围过滤密钥只进环境变量且永远不挂NEXT_PUBLIC_前缀服务端抓用户 URL 走packages/ssrf-safe-fetch这类带白名单的受控入口src/business/与packages/business/里不写商业逻辑、定价与私有基础设施细节。做 i18n/文案变更时不要以为只是文本——文档、文案、注释同样是泄漏向量安全维度对纯文本变更照常运行这是skip_when字段唯一收窄到 lockfile/generated-only 的原因。评审时light 模式完整读 Quick checklistdeep 模式先读 AGENTS.md 安全相关章节与邻居实现按四步流程执行并用rg的五个模式词兜底记住豁免规则的方向性——存量代码里也有同样弱点不是安全问题的减分项而上游已约束输入才是合法的非违规理由且必须引用约束出处。安全维度文件虽短但它把一个 LobeHub 式的多端 AI 产品Web、Electron 桌面端、CLI、Hono 后端服务见 AGENTS.md 项目结构一节中最常见的三类事故——注入、越权、泄漏——压缩成了可执行、可验证、可豁免判定的规则集并通过calibration_exempt与verify: true的组合确保这些发现在整条评审流水线中既不被先例稀释、也不被模型臆断。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考