openai-security-best-practices

安全最佳实践

概述

此技能介绍如何识别当前上下文所用的语言和框架，然后从此技能的 references 目录中加载有关这些语言和框架安全最佳实践的信息。

如果有相关信息，可以用来编写默认安全的代码，也可以主动检测现有代码中的重大问题；或者在用户提出要求时，提供漏洞报告并建议修复方案。

工作流

此技能的初始步骤是识别你需要使用的、或已存在于当前项目范围内的所有语言和所有框架。重点关注核心框架。通常需要同时识别前端和后端的语言与框架。

然后检查此技能的 references 目录，查看是否有适用于这些语言和框架的文档。文件名格式为 <language>-<framework>-<stack>-security.md。还应检查是否存在 <language>-general-<stack>-security.md，这类文档与所用框架无关。

如果要处理的 Web 应用同时包含前端和后端，请务必检查前端和后端的参考文档！

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

如果此技能的 references 目录中没有相关信息，请结合你对该语言、框架及其广为人知的安全最佳实践的了解进行判断。如果不确定，可以尝试在线搜索安全最佳实践文档。

之后，可以按以下几种方式开展工作。

1. 主要模式是从现在起运用这些信息编写默认安全的代码。这适用于启动新项目或编写新代码。

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

3. 用户可以要求提供安全报告或提升代码库的安全性。在这种情况下，应生成一份完整报告，说明项目未遵循安全最佳实践指导的所有方面。报告应按优先级排序，并清楚标明严重程度和紧急程度。然后提出开始着手修复这些问题。请参阅下文的 #fixes。

工作流决策树

• 如果语言或框架不明确，请检查代码仓库以确定它们，并列出依据。
• 如果 references/ 中有适用的指导，只加载相关文件并遵循其中的说明。
• 如果没有适用的指导，请考虑你是否了解所选语言和框架的广为人知的安全最佳实践；但如果用户要求生成报告，应告知用户目前没有具体指导（仍可生成报告，或检测确定无疑的关键漏洞）。

覆盖

虽然这些参考资料包含了适用于各种语言和框架的安全最佳实践，但客户有时可能需要绕过或覆盖这些实践。请留意项目文档和提示词文件中的具体规则和说明，它们可能要求你覆盖某些最佳实践。覆盖某项最佳实践时，你可以告知用户，但不要与用户争执。如果出于项目特定原因需要绕过／忽略某项安全最佳实践，你也可以建议在项目中添加相关文档，说明为何没有遵循该最佳实践，并确保今后继续遵循这一绕过做法。

报告格式

生成报告时，应将报告写入 Markdown 文件 security_best_practices_report.md；如果用户指定了其他位置，则写入该位置。你可以询问用户希望将报告写在哪里。

报告开头应有简短的执行摘要。

报告应根据漏洞严重程度划分为多个清晰的部分。报告应重点关注影响最大的关键发现。所有发现都应标注数字 ID，以便于引用。

对于严重发现，应包含一句影响说明。

报告写好后，也应直接向用户报告，但可以简洁一些。你可以主动提出，如果用户需要，可以进一步解释任何发现或安全最佳实践指导背后的原因。

重要：在报告中引用代码时，务必查找并注明所引用代码的行号。

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

还要告知用户最终报告的保存位置。

修复

如果你生成了报告，应让用户阅读报告，并询问是否开始进行修复。

如果你被动发现了严重问题，应通知用户并询问是否希望你修复该问题。

进行修复时，每次只处理一个发现。添加简洁明确的注释，说明新代码遵循了特定安全最佳实践，并简要说明不这样做可能带来的危险。

始终考虑你计划进行的更改是否会影响用户代码的功能，以及是否可能导致项目回归。务必考虑不安全代码可能因其他原因而被依赖（这也是不安全代码长期存在的原因之一）。避免破坏用户的项目，否则他们可能不愿意再应用安全修复。与其匆忙敷衍地修改，不如结合项目其他部分，审慎充分地制定修复方案。

始终遵循用户配置的常规更改或提交流程。如果进行 Git 提交，应使用清晰的提交消息，说明此次更改旨在遵循安全最佳实践。尽量避免在一次提交中混入多个无关发现。

始终遵循用户配置的常规测试流程（如有），以确认更改不会引入回归。考虑更改可能带来的二阶影响；如有，应在操作前告知用户。

通用安全建议

以下是适用于几乎所有语言或框架的若干安全编码建议。

避免为资源的公开 ID 使用递增编号

为资源分配的 ID 如果将暴露在互联网上，应避免使用较小的自动递增编号。应改用较长的随机 UUID4 或随机十六进制字符串。这样可以防止用户了解资源数量，并猜测资源 ID。

关于 TLS 的说明

虽然 TLS 对生产部署很重要，但大多数开发工作都会在禁用 TLS 的情况下进行，或者由某个不在本项目范围内的 TLS 代理提供 TLS。因此，请务必注意，不要将缺少 TLS 报告为安全问题。对于使用“安全” Cookie，也请务必谨慎。只有在应用实际通过 TLS 运行时，才应设置此类 Cookie。如果在非 TLS 应用中设置（例如部署用于本地开发或测试时），应用将无法正常运行。你可以提供一个环境变量或其他标记来控制是否设置 secure，以便在 TLS 生产部署前保持关闭。此外，请避免建议使用 HSTS。若未充分了解其长期影响（可能导致严重服务中断并使用户无法访问），使用 HSTS 会有风险，而且对于 Agent 审查的项目范围，通常也不建议使用。

适用场景

不适用场景