security-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSecurity Review
安全审查
Overview
概述
Systematically review code for security vulnerabilities, apply secure coding patterns, and ensure applications follow defense-in-depth principles. This skill covers the OWASP Top 10, authentication pattern selection, input validation, secrets management, dependency auditing, security headers, and threat modeling.
Announce at start: "I'm using the security-review skill to assess security posture."
系统地审查代码中的安全漏洞,应用安全编码模式,确保应用遵循深度防御原则。本技能覆盖OWASP Top 10、认证模式选择、输入验证、密钥管理、依赖审计、安全头配置以及威胁建模。
启动时声明: "我正在使用security-review技能评估安全状态。"
Phase 1: Scope and Threat Assessment
第一阶段:范围与威胁评估
Goal: Identify the attack surface and prioritize review areas.
目标: 识别攻击面并确定审查区域优先级。
Actions
执行动作
- Identify all user-facing endpoints and input surfaces
- Map authentication and authorization boundaries
- List external dependencies and their trust levels
- Identify sensitive data flows (PII, credentials, payment)
- Determine compliance requirements (SOC 2, GDPR, HIPAA)
- 识别所有面向用户的端点和输入入口
- 梳理身份认证与授权边界
- 列出外部依赖项及其信任等级
- 识别敏感数据流(个人身份信息PII、凭证、支付信息)
- 明确合规要求(SOC 2、GDPR、HIPAA)
STOP — Do NOT proceed to Phase 2 until:
停止 — 请勿进入第二阶段,直到完成:
- Attack surface is mapped
- Sensitive data flows are identified
- Compliance requirements are known
- 完成攻击面梳理
- 识别所有敏感数据流
- 明确所有合规要求
Phase 2: OWASP Top 10 Audit
第二阶段:OWASP Top 10 审计
Goal: Systematically check against each OWASP category.
目标: 对照每个OWASP类别开展系统性检查。
OWASP Top 10 Checklist (2021)
OWASP Top 10 检查清单(2021版)
| # | Category | Key Check | Pass/Fail |
|---|---|---|---|
| 1 | Broken Access Control | Authorization verified on every endpoint, deny by default | |
| 2 | Cryptographic Failures | No plaintext secrets, strong algorithms (AES-256, bcrypt) | |
| 3 | Injection | Parameterized queries, no string concatenation for SQL/commands | |
| 4 | Insecure Design | Threat model exists, rate limiting, abuse cases considered | |
| 5 | Security Misconfiguration | No defaults in production, minimal permissions, error messages leak nothing | |
| 6 | Vulnerable Components | Dependencies audited, no known CVEs, update policy in place | |
| 7 | Auth Failures | MFA available, passwords hashed, session management secure | |
| 8 | Data Integrity Failures | Verify signatures, validate CI/CD pipeline integrity | |
| 9 | Logging Failures | Log auth events, access control failures, input validation failures | |
| 10 | SSRF | Validate/allowlist URLs, no internal network access from user input |
| # | 类别 | 核心检查项 | 通过/未通过 |
|---|---|---|---|
| 1 | 访问控制失效 | 所有端点均验证授权,默认拒绝访问 | |
| 2 | 加密机制失效 | 无明文密钥,使用强加密算法(AES-256、bcrypt) | |
| 3 | 注入 | 使用参数化查询,SQL/命令执行无字符串拼接 | |
| 4 | 不安全设计 | 存在威胁模型、配置限流、已考虑滥用场景 | |
| 5 | 安全配置错误 | 生产环境无默认配置、权限最小化、错误信息无敏感泄露 | |
| 6 | 存在漏洞的组件 | 依赖已审计、无已知CVE、已制定更新策略 | |
| 7 | 认证失效 | 支持MFA、密码已哈希、会话管理安全 | |
| 8 | 数据完整性失效 | 验证签名、校验CI/CD流水线完整性 | |
| 9 | 日志与监控失效 | 记录认证事件、访问控制失败、输入验证失败日志 | |
| 10 | SSRF(服务器端请求伪造) | URL校验/白名单、用户输入无法访问内部网络 |
STOP — Do NOT proceed to Phase 3 until:
停止 — 请勿进入第三阶段,直到完成:
- All 10 categories are checked
- Findings are documented with severity
- 全部10个类别检查完毕
- 所有发现均已记录并标注严重等级
Phase 3: Deep Review by Category
第三阶段:分类深度审查
Goal: Apply detailed security patterns to identified issues.
目标: 为识别到的问题应用详细的安全修复模式。
Auth Pattern Selection Table
认证模式选择表
| Pattern | Use When | Key Requirements |
|---|---|---|
| JWT | Stateless APIs, microservices, mobile backends | RS256 for multi-service; access token 15min max; HttpOnly cookies |
| Session-based | Traditional web apps, server-rendered pages | Server-side storage; HttpOnly + Secure + SameSite cookies; CSRF tokens |
| OAuth2/OIDC | Third-party login, SSO, delegated auth | Authorization Code + PKCE; validate ID token claims; server-side token storage |
| Passkeys/WebAuthn | Passwordless, high-security apps | Phishing-resistant; store public keys only; support multiple per account |
| 模式 | 适用场景 | 核心要求 |
|---|---|---|
| JWT | 无状态API、微服务、移动端后端 | 多服务场景使用RS256;访问令牌有效期最长15分钟;使用HttpOnly Cookie |
| 基于会话 | 传统Web应用、服务端渲染页面 | 服务端存储会话;配置HttpOnly + Secure + SameSite Cookie;使用CSRF令牌 |
| OAuth2/OIDC | 第三方登录、SSO、委托认证 | 使用授权码+PKCE流程;校验ID Token声明;服务端存储令牌 |
| Passkeys/WebAuthn | 无密码、高安全级别的应用 | 抗钓鱼;仅存储公钥;支持单个账号绑定多个凭证 |
JWT Security Checklist
JWT 安全检查清单
| Aspect | Guidance |
|---|---|
| Signing | RS256 (asymmetric) for multi-service, HS256 for single service |
| Expiry | Access token: 15 minutes max. Refresh token: 7 days max |
| Storage | HttpOnly cookie (web) or secure storage (mobile). Never localStorage |
| Refresh | Rotate refresh tokens on use, invalidate on logout |
| Payload | Minimal claims (sub, exp, iat, roles). No sensitive data |
| 维度 | 规范 |
|---|---|
| 签名 | 多服务场景使用RS256(非对称),单服务场景可使用HS256 |
| 有效期 | 访问令牌最长15分钟,刷新令牌最长7天 |
| 存储 | Web端存HttpOnly Cookie,移动端存安全存储,禁止使用localStorage |
| 刷新 | 刷新令牌使用即轮换,登出时立即失效 |
| Payload | 仅保留最小必要声明(sub、exp、iat、roles),无敏感数据 |
Input Validation Patterns
输入验证模式
Allow-List Validation (always prefer over block-list):
python
undefined白名单验证(优先级始终高于黑名单):
python
undefinedGood: allow-list
推荐:白名单验证
ALLOWED_SORT_FIELDS = {'name', 'created_at', 'price'}
if sort_field not in ALLOWED_SORT_FIELDS:
raise ValidationError("Invalid sort field")
ALLOWED_SORT_FIELDS = {'name', 'created_at', 'price'}
if sort_field not in ALLOWED_SORT_FIELDS:
raise ValidationError("Invalid sort field")
Bad: block-list (always incomplete)
不推荐:黑名单验证(永远存在遗漏)
BLOCKED_CHARS = ['<', '>', '"']
**Parameterized Queries** (never concatenate user input):
```pythonBLOCKED_CHARS = ['<', '>', '"']
**参数化查询**(禁止拼接用户输入):
```pythonGood: parameterized
推荐:参数化查询
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
Bad: SQL injection vulnerability
不推荐:存在SQL注入漏洞
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
undefinedcursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
undefinedFile Upload Validation
文件上传验证
- Validate MIME type server-side (not just extension)
- Enforce file size limits
- Generate random filenames (never use user-supplied names)
- Store uploads outside the web root
- Scan for malware if accepting from untrusted users
- 服务端验证MIME类型(不能仅校验扩展名)
- 强制文件大小限制
- 生成随机文件名(禁止使用用户提供的文件名)
- 存储在Web根目录之外
- 接收不可信用户上传时需扫描恶意软件
STOP — Do NOT proceed to Phase 4 until:
停止 — 请勿进入第四阶段,直到完成:
- All identified issues have remediation recommendations
- Auth patterns are correctly applied
- Input validation is comprehensive
- 所有识别到的问题都有修复建议
- 认证模式已正确应用
- 输入验证覆盖全面
Phase 4: Infrastructure and Dependency Hardening
第四阶段:基础设施与依赖加固
Goal: Secure the deployment environment and supply chain.
目标: 保障部署环境和供应链安全。
Secrets Management Rules
密钥管理规则
| Environment | Method |
|---|---|
| Development | |
| CI/CD | Pipeline secrets (GitHub Secrets, GitLab CI vars) |
| Production | Secrets manager (AWS Secrets Manager, Vault, GCP Secret Manager) |
| 环境 | 管理方式 |
|---|---|
| 开发环境 | |
| CI/CD环境 | 流水线密钥(GitHub Secrets、GitLab CI变量) |
| 生产环境 | 密钥管理服务(AWS Secrets Manager、Vault、GCP Secret Manager) |
Secrets Never List
密钥禁止行为清单
- Never hard-code secrets in source code
- Never commit files to git
.env - Never log secrets (even at debug level)
- Never pass secrets as command-line arguments
- Never use the same secrets across environments
- 禁止在源代码中硬编码密钥
- 禁止将 文件提交到git
.env - 禁止打印密钥日志(即使是debug级别)
- 禁止将密钥作为命令行参数传递
- 禁止跨环境复用相同密钥
Dependency Auditing Commands
依赖审计命令
bash
undefinedbash
undefinedNode.js
Node.js
npm audit
npx socket-security audit
npm audit
npx socket-security audit
Python
Python
pip-audit
safety check
pip-audit
safety check
Go
Go
govulncheck ./...
govulncheck ./...
Rust
Rust
cargo audit
undefinedcargo audit
undefinedSecurity Headers
安全头配置
| Header | Value | Purpose |
|---|---|---|
| | Prevents XSS, data injection |
| | Forces HTTPS |
| | Prevents MIME sniffing |
| | Prevents clickjacking |
| | Controls referer leakage |
| Disable unused APIs | Limits browser feature access |
| 响应头 | 取值 | 作用 |
|---|---|---|
| | 防范XSS、数据注入 |
| | 强制使用HTTPS |
| | 防范MIME类型嗅探 |
| | 防范点击劫持 |
| | 控制Referrer信息泄露 |
| 禁用未使用的API | 限制浏览器功能访问权限 |
CORS Rules
CORS 规则
- Never use with credentials
Access-Control-Allow-Origin: * - Allowlist specific origins
- Restrict allowed methods and headers to what is needed
- 禁止搭配凭证使用
Access-Control-Allow-Origin: * - 配置白名单域名
- 仅允许必要的请求方法和请求头
Phase 5: Threat Modeling (STRIDE)
第五阶段:威胁建模(STRIDE)
Goal: For new features or significant changes, walk through each threat category.
| Threat | Question | Mitigation |
|---|---|---|
| Spoofing | Can an attacker pretend to be someone else? | Strong authentication, MFA |
| Tampering | Can data be modified without detection? | Integrity checks, signatures |
| Repudiation | Can a user deny performing an action? | Audit logging |
| Information Disclosure | Can sensitive data leak through errors, logs, or side channels? | Error sanitization, encryption |
| Denial of Service | Can the system be overwhelmed? | Rate limits, resource quotas |
| Elevation of Privilege | Can a user gain permissions they should not have? | Least privilege, RBAC |
For each identified threat:
- Document the threat and attack vector
- Assess likelihood and impact
- Define mitigations
- Verify mitigations are implemented and tested
目标: 针对新功能或重大变更,逐一排查每个威胁类别。
| 威胁 | 排查问题 | 缓解方案 |
|---|---|---|
| 欺骗(Spoofing) | 攻击者能否冒充其他身份? | 强身份认证、MFA |
| 篡改(Tampering) | 数据能否被未察觉地修改? | 完整性校验、签名 |
| 抵赖(Repudiation) | 用户能否否认自己的操作? | 审计日志 |
| 信息泄露(Information Disclosure) | 敏感数据能否通过错误、日志或侧信道泄露? | 错误信息脱敏、加密 |
| 拒绝服务(Denial of Service) | 系统能否被打垮? | 限流、资源配额 |
| 权限提升(Elevation of Privilege) | 用户能否获取超出自身范围的权限? | 最小权限原则、RBAC |
对每个识别到的威胁:
- 记录威胁和攻击路径
- 评估发生概率和影响范围
- 定义缓解措施
- 验证缓解措施已实现并经过测试
Decision Table: Security Review Depth
决策表:安全审查深度
| Change Type | Review Depth | Focus Areas |
|---|---|---|
| Auth/session changes | Full STRIDE + OWASP | All categories |
| User input handling | Injection + validation focus | OWASP 1, 3, 10 |
| Dependency update | CVE scan + changelog review | OWASP 6 |
| API endpoint addition | Access control + input validation | OWASP 1, 3, 5 |
| Config/infrastructure | Secrets + headers + misconfig | OWASP 2, 5 |
| File upload feature | Injection + SSRF + malware | OWASP 3, 10 |
| 变更类型 | 审查深度 | 重点关注领域 |
|---|---|---|
| 认证/会话变更 | 完整STRIDE+OWASP审查 | 所有类别 |
| 用户输入处理变更 | 重点排查注入+验证 | OWASP 1、3、10 |
| 依赖更新 | CVE扫描+变更日志审查 | OWASP 6 |
| 新增API端点 | 访问控制+输入验证 | OWASP 1、3、5 |
| 配置/基础设施变更 | 密钥+安全头+配置错误 | OWASP 2、5 |
| 新增文件上传功能 | 注入+SSRF+恶意软件 | OWASP 3、10 |
Anti-Patterns / Common Mistakes
反模式/常见错误
| Anti-Pattern | Why It Is Wrong | Correct Approach |
|---|---|---|
| Client-side only validation | Easily bypassed | Always validate server-side |
| Storing tokens in localStorage | XSS can steal them | Use HttpOnly cookies |
| Block-list input validation | Always incomplete | Use allow-list validation |
| Generic error messages in production | May leak internal details | Sanitize errors, log details server-side |
| Same secrets across environments | Breach of one compromises all | Unique secrets per environment |
| Ignoring dependency CVEs | Known vulnerabilities are actively exploited | Audit and update regularly |
| CORS wildcard with credentials | Defeats CORS protection entirely | Allowlist specific origins |
| Logging sensitive data | Log exposure creates data breach | Never log secrets, PII, or tokens |
| 反模式 | 风险 | 正确做法 |
|---|---|---|
| 仅做客户端验证 | 极易被绕过 | 始终在服务端做验证 |
| 将令牌存在localStorage | XSS攻击可窃取令牌 | 使用HttpOnly Cookie |
| 黑名单输入验证 | 永远存在遗漏 | 使用白名单验证 |
| 生产环境返回通用错误信息 | 可能泄露内部细节 | 错误信息脱敏,服务端记录完整日志 |
| 跨环境复用密钥 | 一个环境泄露会波及所有环境 | 每个环境使用独立密钥 |
| 忽略依赖CVE | 已知漏洞会被主动利用 | 定期审计并更新依赖 |
| 搭配凭证使用CORS通配符 | 完全失效CORS保护 | 配置白名单域名 |
| 打印敏感数据日志 | 日志泄露会导致数据泄露 | 禁止打印密钥、PII、令牌日志 |
Secrets Rotation Schedule
密钥轮换计划
| Secret Type | Rotation Frequency | After Suspected Compromise |
|---|---|---|
| API keys | Every 90 days | Immediately |
| Database passwords | Every 90 days | Immediately |
| Encryption keys | Annually (support key versioning) | Immediately |
| JWT signing keys | Every 6 months | Immediately |
| OAuth client secrets | Every 90 days | Immediately |
| 密钥类型 | 轮换频率 | 疑似泄露后处理 |
|---|---|---|
| API密钥 | 每90天 | 立即轮换 |
| 数据库密码 | 每90天 | 立即轮换 |
| 加密密钥 | 每年(支持密钥版本化) | 立即轮换 |
| JWT签名密钥 | 每6个月 | 立即轮换 |
| OAuth客户端密钥 | 每90天 | 立即轮换 |
Subagent Dispatch Opportunities
子Agent调度场景
| Task Pattern | Dispatch To | When |
|---|---|---|
| Scanning different OWASP categories in parallel | | When reviewing a large codebase across multiple vulnerability types |
| Authentication flow analysis | | When auth implementation spans multiple files/services |
| Dependency vulnerability scanning | | When running |
Follow the skill protocol when dispatching.
dispatching-parallel-agents| 任务模式 | 调度对象 | 触发时机 |
|---|---|---|
| 并行扫描不同OWASP类别 | 配置 | 跨多种漏洞类型审查大型代码库时 |
| 认证流程分析 | 配置 | 认证实现跨多个文件/服务时 |
| 依赖漏洞扫描 | 配置 | 并行运行 |
调度时遵循技能协议。
dispatching-parallel-agentsIntegration Points
集成点
| Skill | Relationship |
|---|---|
| Security findings are Critical category issues |
| Backend hardening follows security review findings |
| Auth implementation follows security patterns |
| Security requirements become acceptance criteria |
| Rate limiting serves both security and performance |
| Security incidents trigger debugging workflow |
| 技能 | 关联关系 |
|---|---|
| 安全发现属于严重等级问题 |
| 后端加固基于安全审查发现执行 |
| 认证实现遵循安全模式 |
| 安全要求转化为验收标准 |
| 限流同时满足安全和性能需求 |
| 安全事件触发调试工作流 |
Skill Type
技能类型
FLEXIBLE — Adapt the depth of review to the change type using the decision table. The OWASP checklist and STRIDE analysis are strongly recommended for any auth or input-handling changes. Secrets management rules are non-negotiable.
灵活型 — 根据决策表适配变更类型对应的审查深度。对于任何认证或输入处理变更,强烈建议执行OWASP检查清单和STRIDE分析。密钥管理规则为强制要求。