呱呱 安全与风控
明确请求安全最佳实践、安全审查/报告或安全默认编码且项目使用…
在受支持语言（Python、JavaScript/TypeScript、Go）及其框架的项目中，当用户明确要求安全最佳实践指导、安全审查/报告或安全默认编码帮助时，用于加载对应安全指南、编写安全默认代码、被动检测漏洞或生成并修复安全报告。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 49/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
明确请求安全最佳实践、安全审查/报告或安通用
解决思路
- 识别当前任务或项目范围内所有被要求使用或已存在的语言和框架，优先关注主要核心框架；通常同时识别前端和后端语言与框架。
- 检查本技能 references 目录中是否存在与这些语言或框架相关的文档。
- 确保阅读与特定框架或语言相关的所有 reference 文件；文件名格式为 `<language>-<framework>-<stack>-security.md`。
- 同时检查是否存在框架无关的 `<language>-general-<stack>-security.md`。
- 如果处理包含前端和后端的 Web 应用，确保同时检查前端和后端两边的参考文档。
- 如果要构建包含前端和后端的 Web 应用但未指定前端框架，也查看 `javascript-general-web-frontend-security.md`，以理解如何同时保护前端和后端。
- 如果 references 目录没有相关信息，思考自己已知的该语言、框架及所有众所周知的安全最佳实践；如果不确定，尝试在线搜索安全最佳实践文档。
- 主要模式：利用加载的信息，从现在起直接编写安全默认（secure by default）代码；适用于启动新项目或编写新代码。
- 次要模式：在项目中工作并为用户写代码时，被动检测漏洞；标记关键或非常重要漏洞，或严重违反安全指南的重大问题并告知用户；被动模式聚焦最大影响漏洞和安全默认。
- 用户要求安全报告或提升代码库安全性时，生成完整报告，描述项目未遵循安全最佳实践的所有方式；报告应优先排序，并清晰划分严重性和紧迫性；随后主动提出开始修复这些问题。
- 如果语言或框架不明确，检查仓库来确定它，并列出判断证据。
- 如果 `references/` 中存在匹配指南，仅加载相关文件并遵循其说明。
- 如果不存在匹配指南，考虑自己是否知道所选语言或框架的众所周知安全最佳实践；但如果被要求生成报告，告知用户没有具体指南可用（仍可生成报告或检测确定的关键漏洞）。
- 注意项目文档和提示文件中的特定规则与说明，它们可能要求覆盖某些最佳实践；客户需要绕过或覆盖这些实践时，可以报告给用户，但不要与用户争论。
- 如果安全最佳实践因项目特定原因需要绕过或忽略，建议将原因记录到项目中，以便清楚为什么不遵循该最佳实践，并在未来遵循该绕过。
- 生成报告时，将其写为 markdown 文件 `security_best_practices_report.md`，或用户提供的其他位置；可以询问用户希望报告写到哪里。
- 报告顶部包含简短执行摘要。
- 报告按漏洞严重性清晰划分为多个部分，聚焦最关键发现；所有发现使用数字 ID 标注，便于引用。
- 对关键发现包含一句话影响陈述。
- 在报告中引用代码时，找到并包含所引用代码的行号。
- 报告写完后，也直接向用户报告（可更简洁）；可提出解释任何发现或安全最佳实践指南背后的原因。
- 写完报告文件后，向用户总结发现。
- 告诉用户最终报告写在哪里。
- 如果生成了报告，让用户阅读报告并要求开始执行修复。
- 如果被动发现关键问题，通知用户并询问是否希望修复该发现。
- 生成修复时，一次专注于修复单个发现。
- 修复应包含简洁清晰的注释，解释新代码基于特定安全最佳实践，并可能简短说明不这样做为何危险。
- 始终考虑更改是否影响用户代码功能，是否导致项目当前工作方式回归；不安全代码常因其他原因被依赖，避免破坏用户项目，以免用户未来不愿应用安全修复。
- 优先写出经过深思熟虑、充分了解项目其余部分的修复，而不是快速草率更改。
- 始终遵循用户配置的正常更改或提交流程；若进行 git 提交，提供清晰提交消息，解释这是为了符合安全最佳实践；避免将多个不相关发现混在一个提交中。
- 始终遵循用户配置的正常测试流程（如果有），确认更改未引入回归；考虑更改可能产生的二阶影响，并在做出更改前告知用户（如果有）。
- 通用安全建议：为将暴露到互联网的资源分配 ID 时，避免使用小的自增 ID；改用更长的随机 UUID4 或随机十六进制字符串，以防止用户了解资源数量并猜测资源 ID。
- TLS 注意事项：不要将缺少 TLS 报告为安全问题；大多数开发工作 TLS 禁用或由范围外的 TLS 代理提供。
- “secure” cookies 只应在应用实际通过 TLS 时设置；如果在非 TLS 应用（如本地开发或测试部署）设置，会破坏应用。
- 可提供 env 或其他标志来覆盖 secure 设置，使其在 TLS 生产部署之前保持关闭。
- 避免推荐 HSTS；在不完全理解持久影响（可能导致重大故障和用户锁定）且不在 codex 审查项目推荐范围内时使用很危险。
适用边界 · 注意事项
- 通用代码审查、调试或非安全任务不适用。
- 非支持语言（非 python、javascript/typescript、go）不适用。
- 用户未明确请求安全最佳实践指导、安全审查/报告或安全默认编码帮助时不适用。