Security Review Openai

---
name: "security-review-openai"
description: "执行语言和框架特定的安全最佳实践审查并提出改进建议。仅在用户明确请求安全最佳实践指导、安全审查/报告或默认安全编码帮助时触发。仅对受支持的语言（python、javascript/typescript、go）触发。不要为一般代码审查、调试或非安全任务触发。"
metadata:
  author: OpenAI
  license: Apache-2.0
  version: 2026.02.02
---

# 安全最佳实践

## 概述

本技能提供如何识别当前上下文所用的语言和框架，然后从本技能的 references 目录加载关于该语言和/或框架的安全最佳实践信息的说明。

此信息（如存在）可用于编写新的默认安全代码，或被动检测现有代码中的重大安全问题，或（如用户要求）提供漏洞报告并建议修复。

## 工作流

本技能的第一步是识别您被要求使用或已存在于您工作项目范围内的**所有**语言和**所有**框架。聚焦主要核心框架。通常您会希望同时识别前端和后端的语言与框架。

然后检查本技能的 references 目录，看是否有任何与该语言和/或框架相关的文档。确保阅读与特定框架或语言相关的**所有**参考文件。文件名格式为 `<language>-<framework>-<stack>-security.md`。您还应检查是否存在与您所用框架无关的 `<language>-general-<stack>-security.md`。

如果正在处理一个包含前端和后端的 Web 应用，确保您已检查了**前端和后端两者**的参考文档！

如果您被要求制作一个将同时包含前端和后端的 Web 应用，但未指定前端框架，也请查看 `javascript-general-web-frontend-security.md`。理解如何同时保护前端和后端很重要。

如果技能的 references 目录中没有相关信息，稍微思考一下您对该语言、框架及其所有众所周知的安全最佳实践的了解。如果不确定，可以尝试在线搜索安全最佳实践的文档。

从那里，它可以以几种方式运作。

1. 主要模式是从此刻起仅使用这些信息编写默认安全的代码。这对于启动新项目或编写新代码很有用。

2. 次要模式是在项目中工作和为用户编写代码时被动检测漏洞。关键或非常重要的漏洞或严重违反安全指导的重大问题可以被标记并告知用户。此被动模式应聚焦于影响最大的漏洞和安全默认值。

3. 用户可以要求安全报告或改进代码库的安全性。在这种情况下，应产出一份完整报告，描述项目在哪些方面未遵循安全最佳实践指导。报告应排定优先级，并有清晰的严重性和紧迫性部分。然后提议开始修复这些问题。参见下方 #修复。

## 工作流决策树

- 如果语言/框架不清楚，检查仓库以确定它并列出您的证据。
- 如果 `references/` 中存在匹配的指导，只加载相关文件并遵循其指示。
- 如果不存在匹配的指导，考虑您是否知道所选语言和/或框架的任何众所周知的安全最佳实践，但如果被要求生成报告，让用户知道没有具体指导可用（您仍然可以生成报告或确定性地检测关键漏洞）

# 覆盖（Overrides）

虽然这些参考文件包含语言和框架的安全最佳实践，客户可能有需要绕过或覆盖这些实践的情况。注意项目文档和提示词文件中的特定规则和指示，它们可能要求您覆盖某些最佳实践。覆盖最佳实践时，您**可以**向用户报告，但不要与他们争论。如果某安全最佳实践因项目特定原因需要被绕过/忽略，您也可以建议向项目添加关于此事的文档，以便清楚为何未遵循该最佳实践，并在未来遵循该绕过。

# 报告格式

产出报告时，您应将报告写为 `security_best_practices_report.md` 中的 markdown 文件，或用户提供的其他位置。您可以询问用户希望报告写到哪里。

报告顶部应有简短的高管摘要。

报告应根据漏洞的严重性清晰划分为多个部分。报告应聚焦最关键发现，因为它们对用户影响最大。所有发现都应标注数字 ID 以便引用。

对关键发现，包含一句影响陈述。

报告写好后，也直接向用户报告，不过可以更简洁。如果用户想了解更多关于任何发现的信息，您可以主动解释任何发现或安全最佳实践指导背后的理由。

重要：在报告中引用代码时，确保找到并包含您所引用代码的行号。

写完报告文件后，向用户总结发现。

还要告诉用户最终报告写在了哪里。

# 修复

如果您产出了报告，让用户阅读报告并请求开始执行修复。

如果您被动发现关键发现，通知用户并询问是否希望您修复此发现。

执行修复时，聚焦一次修复单个发现。修复应有简明清晰的注释，说明新代码基于特定的安全最佳实践，也许还有为什么不以这种方式做会危险的极短理由。

始终考虑您要做的更改是否会影响用户代码的功能。考虑更改是否可能导致项目当前工作方式出现回归。不安全的代码经常因其他原因被依赖（这就是不安全代码长期存活的原因）。避免破坏用户的项目，因为这可能使他们在未来不愿应用安全修复。写一个深思熟虑、充分了解项目其余部分的修复，胜过草率仓促的更改。

始终遵循用户配置的任何正常变更或提交流程。如果进行 git 提交，提供清晰的提交信息，说明这是为了与安全最佳实践保持一致。尽量避免将多个无关发现捆绑到单个提交中。

始终遵循用户配置的任何正常测试流程（如有）以确认您的更改没有引入回归。考虑更改可能产生的二阶影响，并在有任何影响时在作出更改前告知用户。

# 一般安全建议

以下是几乎适用于任何语言或框架的几条安全编码建议。

### 避免对资源的公开 ID 使用递增 ID

为某个资源分配 ID（该 ID 随后将暴露于互联网）时，避免使用小的自动递增 ID。改使用更长的、随机的 UUID4 或随机十六进制字符串。这将防止用户得知资源的数量并能够猜测资源 ID。

### 关于 TLS 的说明

虽然 TLS 对生产部署很重要，但大多数开发工作都是在禁用 TLS 或由某个范围外的 TLS 代理提供的情况下进行的。因此，要非常小心不要把缺乏 TLS 报告为安全问题。对"secure"饼干的使用也要非常小心。它们只应在应用实际通过 TLS 运行时设置。如果它们在非 TLS 应用上设置（如为本地开发或测试部署时），会破坏应用。您可以提供 env 或其他标志来覆盖设置 secure，以保持它在 TLS 生产部署前关闭。此外，避免推荐 HSTS。在未完全理解其持久影响的情况下使用它是危险的（可能导致重大中断和用户锁定），且对于 codex 所审查项目的一般范围而言通常不被推荐。