name: 安全最佳实践 description: 执行语言和框架特定的安全最佳实践审查并提出改进建议。仅在用户明确请求安全最佳实践指导、安全审查/报告或默认安全编码帮助时触发。仅针对支持的语言（python、javascript/typescript、go）触发。不适用于一般代码审查、调试或非安全任务。 metadata: author: github.com/openai/skills version: ‘1.0.0’

安全最佳实践

概述

此技能提供了如何识别当前上下文中使用的语言和框架的描述，然后从此技能的参考资料目录中加载有关该语言和/或框架的安全最佳实践信息。

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

工作流程

此技能的初始步骤是识别您被要求使用或已存在于您正在处理的项目范围内的所有语言和所有框架。专注于主要核心框架。通常，您需要识别前端和后端语言和框架。

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

如果处理包括前端和后端的Web应用程序，请确保已检查前端和后端的参考文档！

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

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

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

主要模式是仅使用信息从此开始编写默认安全代码。这对于启动新项目或编写新代码时很有用。
次要模式是在项目中工作并为用户编写代码时被動检测漏洞。可以标记关键或非常重要的漏洞或违反安全指导的主要问题，并告知用户。这种被動模式应关注影响最大的漏洞和安全默认设置。
用户可以要求安全报告或改进代码库的安全性。在这种情况下，应生成完整报告，描述项目未能遵循安全最佳实践指导的任何方面。报告应按优先级排序，并有清晰的严重性和紧急程度部分。然后开始为这些问题提供修复。参见下面的 #修复。

工作流程决策树

如果语言/框架不明确，检查存储库以确定它并列出您的证据。
如果 references/ 中存在匹配指导，仅加载相关文件并遵循其说明。
如果没有匹配指导，考虑您是否了解所选语言和/或框架的任何知名安全最佳实践，但如果要求生成报告，告知用户具体指导不可用（您仍然可以生成报告或检测确定的关键漏洞）

覆盖

虽然这些参考资料包含语言和框架的安全最佳实践，但客户可能有需要绕过或覆盖这些实践的情况。注意项目文档和提示文件中的特定规则和说明，这些可能要求您覆盖某些最佳实践。当覆盖最佳实践时，您可能会报告给用户，但不要与用户争执。如果出于某些项目特定原因需要绕过/忽略安全最佳实践，您还可以建议向项目添加文档，以明确为什么不遵循最佳实践，并将来遵循该绕过。

报告格式

生成报告时，您应将其写为 security_best_practices_report.md 中的markdown文件，或用户提供的其他位置。您可以询问用户希望将报告写入何处。

报告顶部应有简短的执行摘要。

报告应基于漏洞的严重性清晰划分为多个部分。报告应关注最关键的发现，因为这些对用户影响最大。所有发现应编号，以便更容易引用。

对于关键发现，包括一句影响声明。

撰写报告后，还直接向用户报告，尽管可能不那么冗长。如果用户想了解更多关于任何发现或安全最佳实践指导背后的原因，您可以解释。

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

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

还告诉用户最终报告写入的位置。

修复

如果您生成了报告，让用户阅读报告并询问开始执行修复。

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

生成修复时，专注于一次修复一个发现。修复应有简洁清晰的注释，解释新代码基于特定的安全最佳实践，或许一个非常简短的原因说明为什么不这样做会很危险。

始终考虑您要做的更改是否会影响用户代码的功能。考虑更改是否可能导致项目当前工作的回归。通常，不安全代码因其他原因被依赖（这就是为什么不安全代码存在这么久的原因）。避免破坏用户的项目，因为这可能使他们将来不愿应用安全修复。最好编写一个经过深思熟虑、基于项目其余部分信息的修复，而不是一个快速的草率更改。

始终遵循用户配置的任何正常更改或提交流程。如果进行git提交，提供清晰的提交消息，解释这是为了符合安全最佳实践。避免将多个无关发现捆绑到单个提交中。

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

一般安全建议

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

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

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

关于TLS的说明

虽然TLS对于生产部署很重要，但大多数开发工作将在TLS禁用或由某些范围外的TLS代理提供的情况下进行。因此，要非常小心，不要将缺乏TLS报告为安全问题。还要非常小心关于使用“安全”cookie。它们仅应在应用程序实际通过TLS时设置。如果它们在非TLS应用程序上设置（例如部署用于本地开发或测试时），将破坏应用程序。您可以使用环境变量或其他标志来覆盖设置安全，以保持关闭直到TLS生产部署。此外，避免推荐HSTS。在不充分理解其持久影响（可能导致重大中断和用户锁定）的情况下使用它很危险，并且在审查中通常不推荐用于大多数项目。