security-best-practices

安全最佳实践

当任务是指出缺失的一层安全防护，并将其转化为范围明确的加固简报时，请使用此技能。

任务不是罗列一大堆 OWASP 项目、中间件目录或扫描器清单。 任务是：

1. 梳理攻击面和风险，
2. 选择一种主要加固模式，
3. 推荐最小且可信的第一步，
4. 列出验证阶梯，
5. 如实说明相邻工作的处理方式。

请先阅读以下支持文档：

• references/modes-and-boundaries.md
• references/mode-packets-and-route-outs.md
• references/hardening-review-checklist.md
• references/verification-ladder.md

何时使用此技能

• 团队提出“让它更安全”，但缺失的安全防护层仍不明确
• Web 应用、API、营销网站流程、管理面板或游戏服务需要在上线或迁移前进行加固
• 需要判断主要问题是 CSP/标头、Cookie/CSRF、防滥用、验证/不安全执行、机密信息处理，还是验证力度不足
• 需要将扫描器发现、OWASP 要求或上线评审记录转化为一份优先级明确的加固简报
• 当前技术栈已有一些控制措施，但信任度较低，且不清楚下一步该如何验证

何时不使用此技能

• 主要任务是选择身份验证服务商、会话架构、组织/成员模型或企业 SSO 方案 → authentication-setup
• 主要任务是在纳入安全控制之前设计 API 契约/接口 → api-design
• 主要任务是设计架构约束、令牌表、索引或迁移安全性 → database-schema-design
• 主要任务是编写后端回归测试或实现身份验证/安全测试 → backend-testing
• 主要任务是修复代码中的特定漏洞或审查具体差异 → debugging 或 code-review
• 主要任务是机密信息注入机制、工具链引导或环境接线 → system-environment-setup / environment-setup
• 主要任务是云 IAM、VPC/网络或更广泛的基础设施安全 → 使用专门的基础设施技能，而不是此应用加固入口技能

说明

第 1 步：在列出工具前梳理加固任务

先收集最基本的信息。

security_intake:
  surface: frontend | backend-api | fullstack | edge-worker | marketing-site | game-service-web | mixed | unknown
  workflow_type: new-build | hardening-pass | audit-review | launch-readiness | incident-follow-up | migration
  auth_session_model: cookie-session | bearer-token | mixed | unknown
  current_controls:
    - headers-csp
    - csrf
    - rate-limit
    - validation
    - secret-store
    - scanning
    - none
  primary_risk: xss-browser-policy | csrf-session | abuse-automation | injection-unsafe-execution | secret-exposure | verification-gap | mixed | unknown
  environments: local | preview | staging | prod | multi-env | unknown
  ownership: app-team | platform | security | shared | unknown

规则：不要一上来就说“安装 Helmet”“启用 CORS”或“直接添加 WAF 规则”。 首先指出缺失的安全防护层。

第 2 步：只选择一种主要加固模式

使用 references/mode-packets-and-route-outs.md 中的路由规则。

主要模式：

1. browser-perimeter-policy
2. session-cookie-csrf
3. abuse-controls
4. validation-unsafe-execution
5. secrets-runtime-config
6. review-verification

将风险最高的缺失层选为主要模式。 其他所有事项都列为后续工作，不要让它们与主要模式并列负责。

第 3 步：明确列出不变原则

以下规则在所有回答中都适用：

• 即使 CORS、身份验证、CSRF、速率限制、验证和机密信息处理涉及同一条路由，它们仍是不同的问题
• 浏览器策略工作可能需要分阶段推出，或通过仅报告模式进行验证
• 框架默认设置有所帮助，但不能证明覆盖完整
• 机密信息扫描用于检测，并不等同于存储/轮换策略
• WAF 和速率限制是补偿性/边界控制措施，不能完全替代应用层修复
• 每项建议都必须配有相应的验证步骤

第 4 步：编写安全加固简报

按以下结构返回：

# Security Hardening Brief

## Scope
- Surface: ...
- Workflow type: ...
- Primary mode: ...
- Confidence: high | medium | low

## Current control state
- Controls already present: ...
- Missing or untrusted controls: ...

## Highest-risk gaps
1. ...
2. ...
3. ...

## Recommended first slice
1. ...
2. ...
3. ...

## Verification plan
- Manual review: ...
- Static/policy checks: ...
- Dynamic/runtime verification: ...
- Operational evidence: ...

## Ownership and route-outs
- Primary owner: ...
- Adjacent skills / teams: ...

步骤 5：使用模式数据包，而非冗长的检查清单

从 references/mode-packets-and-route-outs.md 获取数据包。

模式规则：

• browser-perimeter-policy → 标头、CSP、框架嵌入、传输安全、仅报告模式的上线、代理/CDN 与应用的责任归属
• session-cookie-csrf → Cookie 标志、会更改状态的浏览器路由、来源假设、Web 与 API/移动端的差异
• abuse-controls → 登录/重置/表单/高开销端点防护、按路由或全局限流、机器人例外、监控
• validation-unsafe-execution → 信任边界、验证/编码、上传、SSRF、命令执行、危险模式
• secrets-runtime-config → 密钥与配置的区分、存储/注入、最小权限、轮换/撤销、避免打包到客户端
• review-verification → 对发现的问题分类、决定保留/修复/添加/延期、最精简的验证阶梯、明确责任归属

步骤 6：明确转交相邻工作

当问题跨越边界时，使用以下转交路径：

如果实际工作是……	转交给……
身份验证供应商选择、企业 SSO、组织/成员模型、托管式与原生身份验证	authentication-setup
API 身份验证/错误/ Webhook 契约设计	api-design
架构约束、令牌表、迁移/数据模型安全	database-schema-design
后端安全回归测试或 CI 门禁	backend-testing
具体漏洞修复或高风险差异审查	debugging / code-review
环境引导或密钥注入配置	system-environment-setup / environment-setup

输出要求

这项技能给出的优质回答应当：

1. 指出主要缺失层，
2. 推荐一个范围明确的首个切入点，
3. 指明验证阶梯，
4. 避免声称某一个库/工具可以解决所有问题，
5. 将相邻工作转交出去，而不是一并纳入。

示例

示例 1：加固基于 Cookie 的管理应用

输入

我们的 Next.js 管理应用使用 Cookie 会话。POST 路由缺少 CSRF 防护，而且预发布环境和生产环境的 Cookie 标志存在偏差。

输出方向

• 选择 session-cookie-csrf
• 指出哪些路由需要 CSRF 防护，以及哪些 Cookie 标志需要修复
• 纳入验证预发布环境和生产环境偏差的步骤
• 避免将任务重新定义为身份验证供应商选择

示例 2：营销网站表单滥用

输入

即使添加了蜜罐和 CAPTCHA，我们的注册表单和演示申请表单仍遭到垃圾信息轰炸。

输出方向

• 选择 abuse-controls
• 将表单滥用控制与通用 CSP/标头工作分开
• 推荐按路由限流/反自动化措施，并进行监控
• 将更广泛的基础设施或供应商规则编写工作排除在核心任务范围之外

示例 3：游戏服务的密钥泄露风险

输入

我们有一个游戏配套网站和后端 API。我担心合作方密钥和管理员令牌会泄漏到 CI 日志中，也可能被打包到客户端。

输出方向

• 选择 secrets-runtime-config
• 将密钥检测与存储/轮换/注入策略分开
• 必要时将环境引导的具体细节转交出去
• 纳入撤销/轮换的验证要求

示例 4：责任归属不明确的扫描器报告

输入

扫描器报告 CSP 较弱且缺少标头，但应用已经添加了中间件，而且没人信任扫描结果。

输出方向

• 选择 review-verification 或 browser-perimeter-policy
• 将中间件安装与上线验证分开
• 推荐分阶段验证/仅报告模式，或扫描器与运行时之间的交接

最佳实践

1. 先选择缺失的安全层，再指定工具。
2. 将浏览器策略、会话安全、滥用控制、验证、密钥和验证工作分别处理。
3. 为每条建议配上能够证明其有效的证据。
4. 将框架默认设置和扫描器结果视为参考输入，而非最终结论。
5. 优先提供一个范围明确的加固任务说明，而不是冗长的合规要求清单。

参考资料

• OWASP 应用程序安全验证标准
• OWASP 备忘单系列
• MDN：内容安全策略
• MDN：Set-Cookie
• OWASP ZAP
• GitHub CodeQL 代码扫描