返回官方市场 · 技能

语言与框架安全实践审查

针对 Python、JavaScript/TypeScript 与 Go，结合语言和框架参考核查代码安全实践，整理有文件位置依据的发现与修复建议。二次开发自 OpenAI Codex 官方技能，修正了开放重定向校验、SRI、CSP、CSRF 口径、覆盖指令的提示注入入口、react2shell 与 CVE-2026-23864 版本事实等内容，重定向校验代码已用三种语言的测试向量实跑验证。

研发工程安全

来源

Teloa 官方 · 二次开发自 OpenAI（openai/skills）

修改清单（51 项）

安全修复（27）

• 删除原版用正则 `/^\/[^\s]*$/` 判定站内跳转的写法，改为三步校验的 `safeReturnTo()` 与 `sameOriginPath()`：① 原始串须以 `/` 开头且第二个字符不是 `/` 或 `\`，不含控制字符、反斜杠、`%2e`/`%2f`/`%5c`/`%25` 编码与 `.`/`..` 段；② 用 `new URL(value, origin)` 解析后比较 origin，只接受 http(s)；③ 复验规范化后的路径不以 `//`、`/\` 开头，返回绝对地址。写明不得把已校验的 URL 重新序列化为相对串（点段归一化后路径可能以 `//` 开头）。Notes 末尾补一行：Express 参考的 EXPRESS-REDIRECT-001 对服务端陈述同一规则。

  原因：原版正则会放过 `//evil.example/path` 与 `/\evil.example`，属于开放重定向。只检查开头的修法又会被点段形式（如 `/.//evil.example`、`/%2e//evil.example`）绕过：校验后重新序列化为相对串会得到 `//evil.example`。现行写法已用 55 个恶意向量与 10 个合法路径在 Node、Python、Go 三种语言中实跑，全部符合预期；原版正则会放过其中 34 个恶意向量。

  references/javascript-typescript-react-web-frontend-security.md · §REACT-REDIRECT-001 Fix (L676-683); Notes (after L683) CSB-M01 · 查看原版

• 把「只允许以 `/` 开头的相对路径」补充为「以 `/` 开头但不以 `//`、`/\` 开头，解析后比较 origin 并复验规范化路径」，并指向 REACT-REDIRECT-001。

  原因：与 REACT-REDIRECT-001 同一类开放重定向问题：只检查 `/` 开头会放过协议相对地址。

  references/javascript-typescript-react-web-frontend-security.md · §REACT-URL-001 Fix (L312) CSB-M02 · 查看原版

• 删除「拒绝协议相对 `//evil.com` 或绝对 URL」的简单口径，改为与 REACT-REDIRECT-001 相同的三步校验，给出带类型的 `safeReturnTo(value: unknown, origin: string, fallback = "/"): string` 与 `NextResponse.redirect(new URL(target, origin))` 示例；指出 `Location: /\evil.example` 会被浏览器当作 `//evil.example`；生产环境应传入配置的规范 origin（`process.env.APP_ORIGIN ?? request.nextUrl.origin`），否则绝对地址与 Location 头会随请求的 Host / X-Forwarded-Host 变化。点段措辞改为「原样发出时仍在本源，重新序列化为相对串后才会变成站外的协议相对地址」。

  原因：原版没有覆盖 `/\` 与点段形式。示例函数与测试所用函数逐字一致，55 个恶意向量全部回退到默认地址；不带类型的写法在 TypeScript strict（noImplicitAny）下无法编译；返回绝对地址后 Location 依赖请求 Host，因此需要规范 origin；原措辞把点段说成直接离开本源，并不准确。

  references/javascript-typescript-nextjs-web-server-security.md · §NEXT-REDIRECT-001 Fix (L764-765) CSB-M03 · 查看原版

• 删除「以 `/` 开头且拒绝 `//host`」的简单口径，改为引用 REACT-REDIRECT-001 的三步校验：`window.location.href = safeReturnTo(route.query.next)`、`router.push(sameOriginPath(route.query.next))`，并禁止 `router.push(route.query.next as string)`。并分开说明：`/\evil.example` 会被浏览器当作 `//evil.example`，无需重新序列化即离开本源；点段形式在重新序列化为相对串后才离开本源。

  原因：同类写法漏掉 `/\` 与点段形式；改为与 React 共用同一个经过测试的函数。

  references/javascript-typescript-vue-web-frontend-security.md · §VUE-ROUTER-002 Fix (L454-455) CSB-M04 · 查看原版

• 给出 `safeReturnTo(raw, fallback)`：原始串策略同 REACT-REDIRECT-001；`url.Parse` 后要求没有 Scheme、Opaque、Host、User；`path.Clean` 后复验不以 `//` 开头，并从解析部件重建 Location。跨源需求用精确的 `(scheme, host)` 允许表，禁止用 `HasPrefix`/`Contains` 比较主机。`path.Clean` 前加注释：它会去掉结尾斜杠，依赖结尾斜杠的路由须在校验后补回。点段措辞改为「原样发出时仍在本源，重新序列化为相对串后才会变成站外的协议相对地址」。

  原因：原版只写「只允许相对路径」，没有给出判定方法。Go 实现用 65 个向量实跑无失败；`path.Clean("/a/b/")` 返回 `"/a/b"` 已实测，所以要提示结尾斜杠。

  references/golang-general-backend-security.md · §GO-REDIRECT-001 Fix (L630-632) CSB-M05 · 查看原版

• 给出只用标准库的 `safe_return_to(value, request_origin)`：先按原始串策略判断，再经 `urlsplit`/`urljoin` 后比较 scheme 与 netloc，然后复验路径不以 `//` 开头，最后返回绝对 URL；注明 Django 的 `url_has_allowed_host_and_scheme` 是同一思路的参考实现。代码块补齐 `import re` 与 `from urllib.parse import urlsplit, urljoin`，`re.split` 改用关键字参数 `maxsplit=1`。用法写明生产环境应传入配置的规范 origin（`current_app.config.get("APP_ORIGIN") or request.host_url.rstrip("/")`）。点段措辞改为「原样发出时仍在本源，重新序列化为相对串后才会变成站外的协议相对地址」。

  原因：原版只有笼统口径，没有可用的判定方法。Python 实现用 65 个向量实跑无失败；Python 3.13 起按位置传 maxsplit 会触发 DeprecationWarning，改后在把告警视为错误的模式下运行无告警。

  references/python-flask-web-server-security.md · §FLASK-REDIRECT-001 Fix (L566-567) CSB-M06 · 查看原版

• 给出与 FLASK-REDIRECT-001 逐字相同的 `safe_return_to()`，用法为 `RedirectResponse(safe_return_to(request.query_params.get("next"), settings.APP_ORIGIN or str(request.base_url).rstrip("/")))`；同样补齐导入、改用 `maxsplit=1`，并写明生产环境应传入配置的规范 origin。点段措辞改为「原样发出时仍在本源，重新序列化为相对串后才会变成站外的协议相对地址」。

  原因：与 FLASK-REDIRECT-001 相同：原版缺少判定方法；65 个向量实跑无失败，改后的写法在把告警视为错误时没有 DeprecationWarning。

  references/python-fastapi-web-server-security.md · §FASTAPI-REDIRECT-001 Fix (L850) CSB-M07 · 查看原版

• 删除「拿不到 SRI 哈希就跳过；用错导致无法加载时去掉 integrity」。改为：integrity 不匹配说明字节与哈希不符——先确认锁定的版本与文件，从官方下载页取哈希或自行计算并带算法前缀（如 `integrity="sha384-…"`，可用 `openssl dgst -sha384 -binary … | openssl base64 -A` 计算），保留 `crossorigin="anonymous"`；没有可信哈希就改用 npm 打包或自托管；哈希正确仍失败时先排除 CORS（缺 `crossorigin` 或 CDN 未返回 ACAO，控制台会报与 CORS 相关的错误），确认是 integrity 错误后保持失败，并按供应链事件上报。

  原因：原建议会让字节完整性校验失效，且与同一节前文要求使用 SRI 的写法（L198、L202）矛盾。

  references/javascript-jquery-web-frontend-security.md · §JQ-SUPPLY-002 Note (L215) CSB-M08 · 查看原版

• 把「只需设置 script-src，其余 CSP 指令为方便开发可整体省略」改为：script-src 优先，首选 nonce/hash 加 `'strict-dynamic'`（主机允许表可经 JSONP 或开放重定向绕过）；不得整体省略其余指令，`object-src 'none'` 与 `base-uri` 用于封堵 script-src 绕过，`frame-ancestors` 是点击劫持防护（只在响应头中生效）；其余指令按应用实际加载、嵌入与提交的目标定制，先用 report-only 迭代。并补充：用 `<meta>` 交付时 frame-ancestors、report-uri、sandbox 会被忽略，report-only 只能通过响应头使用。

  原因：原文把安全建议写成「可省略其余指令」，与同一文件对 frame-ancestors 和点击劫持的要求冲突；缺少 object-src、base-uri 的 CSP 可以被绕过。

  references/javascript-jquery-web-frontend-security.md · §3.3 CSP + Trusted Types (L137) CSB-M09 · 查看原版

• 把「只需设置 script-src，其余 CSP 指令为方便开发可整体省略」改为：script-src 优先，首选 nonce/hash 加 `'strict-dynamic'`（主机允许表可经 JSONP 或开放重定向绕过）；不得整体省略其余指令，`object-src 'none'` 与 `base-uri` 用于封堵 script-src 绕过，`frame-ancestors` 是点击劫持防护（只在响应头中生效）；其余指令按应用实际加载、嵌入与提交的目标定制，先用 report-only 迭代。

  原因：原文把安全建议写成「可省略其余指令」，与同一文件对 frame-ancestors 和点击劫持的要求冲突；缺少 object-src、base-uri 的 CSP 可以被绕过。

  references/javascript-express-web-server-security.md · §EXPRESS-HEADERS-001 NOTE (L199) CSB-M10 · 查看原版

• 把「只需设置 script-src，其余 CSP 指令为方便开发可整体省略」改为：script-src 优先，首选 nonce/hash 加 `'strict-dynamic'`（主机允许表可经 JSONP 或开放重定向绕过）；不得整体省略其余指令，`object-src 'none'` 与 `base-uri` 用于封堵 script-src 绕过，`frame-ancestors` 是点击劫持防护（只在响应头中生效）；其余指令按应用实际加载、嵌入与提交的目标定制，先用 report-only 迭代。

  原因：原文把安全建议写成「可省略其余指令」，与同一文件对 frame-ancestors 和点击劫持的要求冲突；缺少 object-src、base-uri 的 CSP 可以被绕过。

  references/javascript-general-web-frontend-security.md · §JS-CSP-001 NOTE (L371); §JS-CSP-002 NOTE (L407) CSB-M11 · 查看原版

• 把「只需设置 script-src，其余 CSP 指令为方便开发可整体省略」改为：script-src 优先，首选 nonce/hash 加 `'strict-dynamic'`（主机允许表可经 JSONP 或开放重定向绕过）；不得整体省略其余指令，`object-src 'none'` 与 `base-uri` 用于封堵 script-src 绕过，`frame-ancestors` 是点击劫持防护（只在响应头中生效）；其余指令按应用实际加载、嵌入与提交的目标定制，先用 report-only 迭代。

  原因：原文把安全建议写成「可省略其余指令」，与同一文件对 frame-ancestors 和点击劫持的要求冲突；缺少 object-src、base-uri 的 CSP 可以被绕过。

  references/golang-general-backend-security.md · §GO-HTTP-004 (L313) CSB-M12 · 查看原版

• 把「只需设置 script-src，其余 CSP 指令为方便开发可整体省略」改为：script-src 优先，首选 nonce/hash 加 `'strict-dynamic'`（主机允许表可经 JSONP 或开放重定向绕过）；不得整体省略其余指令，`object-src 'none'` 与 `base-uri` 用于封堵 script-src 绕过，`frame-ancestors` 是点击劫持防护（只在响应头中生效）；其余指令按应用实际加载、嵌入与提交的目标定制，先用 report-only 迭代。

  原因：原文把安全建议写成「可省略其余指令」，与同一文件对 frame-ancestors 和点击劫持的要求冲突；缺少 object-src、base-uri 的 CSP 可以被绕过。

  references/javascript-typescript-nextjs-web-server-security.md · §NEXT-CSP-001 NOTE (L496) CSB-M13 · 查看原版

• 把「只需设置 script-src，其余 CSP 指令为方便开发可整体省略」改为：script-src 优先，首选 nonce/hash 加 `'strict-dynamic'`（主机允许表可经 JSONP 或开放重定向绕过）；不得整体省略其余指令，`object-src 'none'` 与 `base-uri` 用于封堵 script-src 绕过，`frame-ancestors` 是点击劫持防护（只在响应头中生效）；其余指令按应用实际加载、嵌入与提交的目标定制，先用 report-only 迭代。

  原因：原文把安全建议写成「可省略其余指令」，与同一文件对 frame-ancestors 和点击劫持的要求冲突；缺少 object-src、base-uri 的 CSP 可以被绕过。

  references/python-django-web-server-security.md · §DJANGO-CSP-001 NOTE (L646) CSB-M14 · 查看原版

• 删除「忽略开发工具和打包器的 npm audit 结果」。改为按可达性分级：请求路径上的依赖优先处理，但不得整体忽略 devDependencies——构建与 CI 工具能接触源码、凭据和发布令牌，开发依赖只要被安装（开发机、未加 `--omit=dev` 的 CI），其安装脚本就会执行；确认不可达且没有安装脚本后才可降级。

  原因：与 React 参考 REACT-SUPPLY-001 把构建工具与安装脚本攻击纳入范围的要求冲突；整体排除开发依赖会漏掉构建与 CI 的供应链风险。

  references/javascript-express-web-server-security.md · §EXPRESS-DEPS-001 NOTE (L919) CSB-M15 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/javascript-typescript-react-web-frontend-security.md · §REACT-CSRF-001 NOTE (L552) CSB-M16 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/javascript-jquery-web-frontend-security.md · §JQ-AJAX-002 NOTE (L418) CSB-M17 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。Required 首条的「that rely on cookies for authentication」同步改为「rely on ambient credentials (cookies, HTTP Basic/Digest, TLS client certificates)」。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/javascript-express-web-server-security.md · §EXPRESS-CSRF-001 IMPORTANT NOTE (L368, L379); Required #1 (L372) CSB-M18 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。Required 首条的「that rely on cookies for authentication」同步改为「rely on ambient credentials (cookies, HTTP Basic/Digest, TLS client certificates)」，与上方说明一致。「If tokens are impractical」一条中的自定义请求头要求补上前提「(combined with strict CORS and `SameSite` cookies)」，与 Express 参考一致。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/golang-general-backend-security.md · §GO-HTTP-006 IMPORTANT NOTE (L365); Required #1 (L368); "If tokens are impractical" (L372) CSB-M19 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/javascript-typescript-nextjs-web-server-security.md · §NEXT-CSRF-001 IMPORTANT NOTE (L340) CSB-M20 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/javascript-typescript-vue-web-frontend-security.md · §VUE-CSRF-001 NOTE (L494) CSB-M21 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。Required 首条的「that rely on cookies for authentication」同步改为「rely on ambient credentials (cookies, HTTP Basic/Digest, TLS client certificates)」。「If tokens are impractical」一条中的自定义请求头要求补上前提「(combined with strict CORS and `SameSite` cookies)」，与 Express 参考一致。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。

  references/python-flask-web-server-security.md · §FLASK-CSRF-001 IMPORTANT NOTE (L240); Required #1 (L243); "If tokens are impractical" (L247); Fix, last item (L260) CSB-M22 · 查看原版

• 把「不用 cookie 认证就没有 CSRF 风险」的绝对表述改为：浏览器会自动附带的凭据（会话 cookie、HTTP Basic/Digest、TLS 客户端证书）都会引发 CSRF；只有当所有受保护端点只接受脚本显式设置的 `Authorization: Bearer`、不接受任何自动附带的凭据时，经典的浏览器 CSRF 才不适用，并要求确认这些端点没有同时接受 cookie 会话。同时把 L398 残留的「If cookies are not used for auth … CSRF is usually not applicable」改为指向上文的自动附带凭据规则。Required 首条的「that rely on cookies for authentication」同步改为「rely on ambient credentials (cookies, HTTP Basic/Digest, TLS client certificates)」。

  原因：原口径会让审查者对使用 HTTP Basic/Digest、客户端证书以及混用 cookie 的端点跳过 CSRF 检查，得出不安全的结论；各参考文件在这一点上统一为完整口径。L398 的残留句与新口径矛盾。

  references/python-fastapi-web-server-security.md · §FASTAPI-CSRF-001 Note (L391); Required #1 (L395); Required, last item (L398) CSB-M23 · 查看原版

• 重写 react2shell 段：编号改为 CVE-2025-55182（React）/ GHSA-9qr9-h5gf-34mp（Next.js），注明 CVE-2025-66478 已被 NVD 以重复为由拒绝；写明受影响范围（15.x、16.x、14.3.0-canary.77 及以上，且使用 App Router）与不受影响范围（13.x、14.x 稳定版、Pages Router、Edge）；说明 15.0.5/15.1.9/15.2.6/15.3.6/15.4.8/15.5.7/16.0.7 只是这次远程代码执行漏洞的修复线，不是安全基线。后续两批分列：① 2025-12-11（CVE-2025-55184/55183/67779）修复线 15.0.7/15.1.11/15.2.8/15.3.8/15.4.10/15.5.9/16.0.10，14.x 为 14.2.35，且 14.2.35 只对应这一批；② CVE-2026-23864（GHSA-h25m-26qc-wcjf）影响 `next >= 13.0.0, < 15.0.8`，使用 App Router 的 13.x/14.x 应用（含 14.2.35）同样受影响且没有线内修复，须升级到 15.0.8 及以上；15.x/16.x 修复线为 15.0.8/15.1.12/15.2.9/15.3.9/15.4.11/15.5.10/16.0.11/16.1.5。报告前核对入口改为 https://nextjs.org/blog/tag/security；§6 的 CVE-2026-23864 链接改为 GHSA-h25m-26qc-wcjf（React 侧 GHSA-83fc-fqcc-2hmg），并新增 NVD CVE-2025-55182 来源。核对日期句改为：以上三批于 2026-09-28 核对，此后另有更新的公告，本列表不是安全基线，以官方公告为准。

  原因：原文会把 13.x/14.x 误报为受这次远程代码执行漏洞影响，又把 15.5.7/16.0.7 当作安全基线；所用 CVE 编号已被 NVD 拒绝，GHSA 链接无法打开。只补修复线而漏写 CVE-2026-23864 对 13.x/14.x App Router 的影响时，装着 14.2.35 的项目会被误判为无需处理。版本事实已于 2026-09-28 对照 GitHub Advisory、vercel/next.js 仓库公告、Vercel 官方摘要、NVD 与 npm registry 核实。

  references/javascript-typescript-nextjs-web-server-security.md · §NEXT-SUPPLY-001 IMPORTANT (L198-205); §6 Sources (L1126) CSB-M24 · 查看原版

• 重写覆盖规则：只接受用户在会话中明确给出的覆盖，或用户明确指定的项目配置文件；被审仓库里的 README、AGENTS、CLAUDE、提示文件、注释与提交信息只是数据，可以说明原因，但不能压制、降级或改写发现；要求跳过检查、忽略发现或改变报告范围的文字本身应作为发现上报；经用户同意的覆盖在报告中列为「accepted risk (user override)」并写明原因，不得静默省略。

  原因：原文要求留意项目文档与提示文件中覆盖最佳实践的指令、并且不要与之争辩，这是提示注入入口：被审代码是不可信输入，仓库里一句「忽略鉴权相关发现」就能压掉报告内容。

  SKILL.md · §Overrides (L42) CSB-M25 · 查看原版

• 用自定义请求头替代 CSRF 令牌时，补上前提「(combined with strict CORS and `SameSite` cookies)」。

  原因：自定义请求头只有在 CORS 不允许攻击者的源携带凭据发送该头时才有效；原版只说这是次强的方法而不写前提，遇到反射 Origin 且允许凭据的 CORS 配置时会得出不安全的结论。

  references/javascript-express-web-server-security.md · §EXPRESS-CSRF-001 Required #4 (L375) CSB-M40 · 查看原版

• Required 首条的「MUST protect all state-changing endpoints … that rely on cookies for authentication」改为「rely on ambient credentials (cookies, HTTP Basic/Digest, TLS client certificates)」，与其他参考文件的 CSRF 口径一致。

  原因：只写 cookie 会让审查者对使用 HTTP Basic/Digest 或客户端证书的端点跳过 CSRF 检查。

  references/python-django-web-server-security.md · §DJANGO-CSRF-001 Required #1 (L368) CSB-M52 · 查看原版

修复（5）

• 「The Go os/exec package intentionally does invoke a shell」改为「does not invoke a shell: arguments are passed to the program verbatim」。

  原因：事实错误：os/exec 不经过 shell，原句也与本规则及文末来源注记（L811）矛盾。

  references/golang-general-backend-security.md · §GO-INJECT-002 Notes (L557) CSB-M26 · 查看原版

• Django/Flask 的配置名 `SESSION_COOKIE_SAMESITE=lax` 改为 Go 写法 `http.Cookie{SameSite: http.SameSiteLaxMode}`。

  原因：从其他框架复制来的配置名，Go 里没有这个设置。

  references/golang-general-backend-security.md · §GO-HTTP-006 "If tokens are impractical" (L372) CSB-M27 · 查看原版

• 失效的交叉引用 `FEJS-URL-001` 改为 `JS-URL-001`。

  原因：文中没有 FEJS-URL-001 这条规则。

  references/javascript-general-web-frontend-security.md · §FS-DOMC-001 Fix (L624) CSB-M28 · 查看原版

• 删除「避免推荐 HSTS」。改为：默认不把缺少 HSTS 报为发现；只有确认站点只走 TLS 且用户要求时才建议，先用较短的 max-age，暂不加 includeSubDomains 与 preload，并指向 Django 参考中的渐进做法。

  原因：原文与 Django 参考（L115、L257、L273）建议启用 HSTS 的写法冲突。

  SKILL.md · §General Security Advice / A note on TLS (L86) CSB-M29 · 查看原版

• 原句「MUST NOT use use `.format()` on user controlled strings」改为：格式串本身受用户控制属于格式串注入；并且无论格式串归谁控制，只要格式化或拼接的结果作为模板源传给 `render_template_string`/`Environment.from_string`，就是 SSTI（Critical），例如 `render_template_string(f"Hello {request.args['name']}")`；只有结果作为普通字符串输出时，才属于按输出上下文转义的较低风险问题。Insecure patterns 补上 `render_template_string("Hello %s" % name)` 与 f-string 拼接两种写法。并补一句：用户控制的格式串即使结果只作为字符串输出，仍属格式串注入。

  原因：原句有重复词，且没有说清风险在哪里；Flask 最常见的 SSTI 写法（开发者写的格式串拼进用户值，再作为模板源）容易被当作较低风险，从而降级一条 Critical 规则。

  references/python-flask-web-server-security.md · §FLASK-SSTI-001 Required (L303); Insecure patterns (L311) CSB-M30 · 查看原版

移除（1）

• 不再随附 `agents/openai.yaml`（Codex 客户端的界面展示信息：display_name、short_description、default_prompt）。

  原因：该文件只被 Codex 客户端读取，Teloa 不使用；标题与简介由市场目录条目提供。

  agents/openai.yaml · whole file CSB-M41 · 查看原版

适配（12）

• 去掉「not generally recommended for the scope of projects being reviewed by codex」中专指 Codex 的措辞。

  原因：让说明对 Teloa 等其他客户端应用保持中性；HSTS 建议本身的更正见 CSB-M29。

  SKILL.md · §A note on TLS (L86) CSB-M31 · 查看原版

• 在 SKILL.md 标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md；10 份参考文件的同一声明分别见 CSB-M42～CSB-M51。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  SKILL.md · below the title CSB-M32 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/golang-general-backend-security.md · below the title CSB-M42 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/javascript-express-web-server-security.md · below the title CSB-M43 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/javascript-general-web-frontend-security.md · below the title CSB-M44 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/javascript-jquery-web-frontend-security.md · below the title CSB-M45 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/javascript-typescript-nextjs-web-server-security.md · below the title CSB-M46 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/javascript-typescript-react-web-frontend-security.md · below the title CSB-M47 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/javascript-typescript-vue-web-frontend-security.md · below the title CSB-M48 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/python-django-web-server-security.md · below the title CSB-M49 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/python-fastapi-web-server-security.md · below the title CSB-M50 · 查看原版

• 在标题下方加一行显著的修改声明「Derived work: modified by Teloa from openai/skills@49f948fa…」，并指向 MODIFICATIONS.md。

  原因：Apache-2.0 第 4(b) 条要求被修改的文件带有显著的修改声明。

  references/python-flask-web-server-security.md · below the title CSB-M51 · 查看原版

新增（3）

• 新增一段：参考文件的内容截至 2026 年 1 月，报告中涉及版本号、最新版本与 CVE 时，须先对照当前官方公告核实并引用出处。

  原因：参考文件中的版本与漏洞事实会过时，直接引用可能给出错误的升级建议。

  SKILL.md · §Workflow (after L25) CSB-M33 · 查看原版

• 新增：Go 1.25 及以上 SHOULD 使用 `http.NewCrossOriginProtection().Handler(mux)`——按 `Sec-Fetch-Site` 拒绝不安全的跨源请求，缺该头时回退比较 `Origin` 与 `Host`，两者都缺时放行；GET/HEAD/OPTIONS 一律放行；代理改写 Host 时用 `AddTrustedOrigin`；需要兼容两个头都不发送的客户端时保留令牌；不要用 GET 改状态（CrossOriginProtection 与 SameSite=Lax 都拦不住跨站顶层 GET），应改用 POST/PUT/PATCH/DELETE。为容纳这条新防线，原版 L370「tokens remain the primary defense」改为「主防线是 CSRF 令牌或 Go 1.25+ CrossOriginProtection，其余为纵深防御」。

  原因：这份参考以 Go 1.25.x 为目标，却没有提到标准库自带的 CSRF 防护；行为描述已与 pkg.go.dev 文档逐项核对。L370 的改写是为容纳新增防线，不是纠正原版错误，所以随本条归为新增。

  references/golang-general-backend-security.md · §GO-HTTP-006 Required (L370 rewritten; new item after it) CSB-M34 · 查看原版

• 新增一句：Werkzeug `safe_join` 的设备名处理有多次后续修复（CVE-2025-66221 在 3.1.4 修复、CVE-2026-21860 在 3.1.5 修复、CVE-2026-27199 在 3.1.6 修复），以当前 Werkzeug 公告为准。

  原因：原版文件的抓取日（2026-01-26）之前 CVE-2026-21860 已经发布，但文中没有列出。

  references/python-flask-web-server-security.md · §FLASK-SUPPLY-001 Audit focus (L626) CSB-M35 · 查看原版

优化（3）

• 修正语病「MUST use at a minimum require」，「CRSF」改为「CSRF」，「second strongest」改为「next strongest」，并补上「on state-changing requests」。

  原因：拼写、语法与表述清晰度；同一行新增的安全前提单列为 CSB-M40。

  references/javascript-express-web-server-security.md · §EXPRESS-CSRF-001 Required #4 (L375) CSB-M37 · 查看原版

• 拼写：「tot eh」改为「on the」，「concent」改为「consent」。

  原因：拼写错误。

  references/javascript-express-web-server-security.md · §EXPRESS-STATIC-001 Severity (L644); §EXPRESS-DEPS-001 (L921) CSB-M38 · 查看原版

• 拼写：「concent」改为「consent」。

  原因：拼写错误。

  references/javascript-jquery-web-frontend-security.md · §JQ-SUPPLY-001 NOTE (L159) CSB-M39 · 查看原版

其余 1 个文件与原版一致（已校验）

GitHub

资源文件：catalog/skills/openai.security-best-practices.json
市场保存的文件：artifacts/skills/openai.security-best-practices/1.0.0/
原始来源（锁定版本）：GitHub openai/skills@49f948f

许可

Apache-2.0
许可文件：LICENSE.txt

审核

审核人 Teloa，2026-09-28

兼容状态

仅提供内容 · 适用 Teloa >=0.2.0-alpha.7 · DSH 0.1.7-rc.1

• 仅用于明确请求的 Python、JavaScript/TypeScript、Go 安全编码与审查；需提供授权的代码范围和目标框架版本。
• 静态审查使用原生文件读取与搜索；保存报告需要写入权限。无必装的第三方技能、MCP 或专用凭据。
• 联网查文档、npm audit、govulncheck、项目测试和修复都是条件路径：修复需要编辑，运行测试或扫描需要 Shell，运行前核对授权、工具与网络。npm audit 会向 registry 发送依赖树，不应上传源码或密钥。
• 所附参考资料的内容截至 2026 年 1 月，并经 Teloa 二次开发修正；版本号与 CVE 需对照当前官方公告复核；静态发现不是安全认证。未完成真实模型任务验证。

权限与需求

工具：read, glob, grep, write, edit, bash
使用时联网：是

数据流向

文件已随 Teloa 安装包提供，添加时不用联网下载。 浏览本站无需登录；访问量用 Cloudflare Web Analytics 统计，不使用 Cookie，不记录个人身份。 登录与发表评价的数据处理：隐私与社区规则

技能 openai.security-best-practices · 版本 1.0.0

问题反馈