security

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/security — Security-First Design Enforcement

/security — 安全优先设计强制规范

Every design, plan, and implementation MUST treat security as a first-class constraint, not an afterthought. Vulnerabilities are bugs — the most expensive kind.

Why this matters: A single security vulnerability can compromise user data, destroy trust, and cost millions in breach response. Security cannot be "added later" — it must be designed in from the start. Every line of code is an attack surface.

When to invoke: During PLANNING (after brainstorming, before or alongside writing-plans) and during REVIEW (as part of code review criteria). This skill applies to ALL code — there are no exceptions for "internal" or "low-risk" systems.

所有设计、规划和落地工作都必须将安全视为第一优先级约束，而非事后补充项。漏洞是代价最高的一类bug。

为什么这很重要： 单个安全漏洞就可能泄露用户数据、摧毁用户信任，还会产生数百万的漏洞响应成本。安全无法“事后补上”——必须从一开始就纳入设计。每一行代码都是攻击面。

何时适用： 规划阶段（头脑风暴后，编写方案期间或之前）以及评审阶段（作为代码评审标准的一部分）。本规范适用于所有代码——“内部”或“低风险”系统也不例外。

The Rules

规范规则

Rule 1: Validate All Input at System Boundaries

规则1：在系统边界校验所有输入

Every piece of data entering the system MUST be validated before use:

Boundary	What to validate
HTTP requests	Body, query params, headers, path params — type, length, format, range
File uploads	Type, size, content (not just extension), filename sanitization
Database reads	Assume data could be corrupted — validate on read if used in security decisions
Environment variables	Type, format, required vs optional — fail fast on invalid config
External API responses	Schema validation — don't trust upstream services blindly
User-generated content	Sanitize for XSS, SQL injection, path traversal, command injection

Allowlist over denylist. Define what IS allowed, never what ISN'T. Attackers are creative; your denylist isn't.

所有进入系统的数据在使用前必须完成校验：

边界	校验内容
HTTP 请求	请求体、查询参数、请求头、路径参数 — 校验类型、长度、格式、取值范围
文件上传	文件类型、大小、实际内容（不单单校验扩展名）、文件名 sanitization
数据库读取	假设数据可能已损坏，若用于安全决策则读取时必须校验
环境变量	校验类型、格式、必填/可选属性，配置非法时快速失败
外部 API 响应	做 schema 校验，不要盲目信任上游服务
用户生成内容	做XSS、SQL注入、路径遍历、命令注入防护的 sanitization 处理

优先用允许名单而非禁止名单。 明确定义允许的内容，而非列举禁止的内容。攻击者的手段层出不穷，你的禁止名单永远覆盖不全。

Rule 2: Authentication and Authorization

规则2：身份认证与权限控制

Principle	Requirement
Authentication	Every endpoint must know who is calling. No anonymous access unless explicitly designed.
Authorization	Every operation must check if the caller is ALLOWED to do this. Auth ≠ authz.
Least privilege	Grant the minimum permissions needed. No admin-by-default.
Session management	Secure tokens (HttpOnly, Secure, SameSite), reasonable TTL, revocation support.
Password handling	bcrypt/scrypt/argon2 only. Never MD5/SHA for passwords. Never store plaintext.
API keys	Scoped, rotatable, revocable. Never embedded in client-side code.

Every endpoint MUST have an explicit auth decision — either "this requires auth" or "this is intentionally public" (documented why).

原则	要求
身份认证（Authentication）	每个接口必须识别调用方身份，除非明确设计为匿名访问
权限授权（Authorization）	每个操作都必须校验调用方是否拥有执行权限，身份认证≠权限授权
最小权限原则	授予操作所需的最低权限，默认不分配管理员权限
会话管理	使用安全令牌（开启HttpOnly、Secure、SameSite属性）、合理的有效期、支持吊销机制
密码处理	仅使用bcrypt/scrypt/argon2算法加密，禁止用MD5/SHA处理密码，永远不存储明文密码
API 密钥	限定作用范围、支持轮换、支持吊销，永远不要嵌入到客户端代码中

每个接口必须有明确的身份认证决策 —— 要么“该接口需要身份认证”，要么“该接口特意设为公开”（需文档说明原因）。

Rule 3: Secrets Management

规则3：密钥管理

Secrets MUST NEVER appear in:

Source code (no hardcoded passwords, API keys, tokens)
Git history (if committed accidentally, rotate immediately — don't just delete)
Logs (mask/redact sensitive fields)
Error messages (no stack traces with connection strings in production)
Client-side code (no API keys in JavaScript bundles)

Secrets MUST live in:

Environment variables (minimum)
Secrets manager (AWS Secrets Manager, Vault, 1Password) for production
```
.env
```
files that are in
```
.gitignore
```
for local development

密钥永远不能出现在以下位置：

源代码中（不要硬编码密码、API密钥、令牌）
Git 历史中（如果不小心提交了，立刻轮换密钥 —— 不要只是删除文件）
日志中（敏感字段要做掩码/脱敏处理）
错误信息中（生产环境不要返回带连接字符串的栈追踪信息）
客户端代码中（JavaScript 打包产物中不要包含API密钥）

密钥必须存储在：

环境变量（最低要求）
生产环境使用密钥管理工具（AWS Secrets Manager、Vault、1Password）
本地开发环境使用加入
```
.gitignore
```
的
```
.env
```
文件存储

Rule 4: Defense in Depth

规则4：深度防御

No single security control is sufficient. Layer defenses:

Layer 1: Network — firewalls, VPN, TLS everywhere
Layer 2: Application — input validation, output encoding
Layer 3: Authentication — verify identity at every boundary
Layer 4: Authorization — check permissions for every operation
Layer 5: Data — encryption at rest and in transit
Layer 6: Monitoring — log security events, alert on anomalies

If any single layer fails, the remaining layers MUST still protect the system. Never rely on "the firewall will stop it" or "users won't do that."

单一安全控制措施是不够的，要做分层防御：

Layer 1: Network — firewalls, VPN, TLS everywhere
Layer 2: Application — input validation, output encoding
Layer 3: Authentication — verify identity at every boundary
Layer 4: Authorization — check permissions for every operation
Layer 5: Data — encryption at rest and in transit
Layer 6: Monitoring — log security events, alert on anomalies

如果任意一层失效，剩余的层必须仍能保护系统安全。永远不要依赖“防火墙会拦住攻击”或者“用户不会这么操作”这类假设。

Rule 5: Secure Defaults

规则5：安全默认配置

Every configuration, feature flag, and permission MUST default to the secure option:

New users get minimum permissions, not admin.
New endpoints require authentication, not allow anonymous.
New features are disabled until explicitly enabled.
CORS is restrictive until explicitly opened.
CSP is strict until explicitly relaxed.
TLS is required, not optional.

"Opt into risk, never opt out of safety."

所有配置、功能开关、权限的默认值都必须是最安全的选项：

新用户默认分配最低权限，而非管理员权限
新接口默认需要身份认证，而非允许匿名访问
新功能默认关闭，直到明确开启
CORS 默认限制访问，直到明确放开
CSP 默认严格限制，直到明确放宽
TLS 默认强制开启，而非可选

“永远选择主动规避风险，而不是主动放弃安全”。

Rule 6: Dependency Security

规则6：依赖安全

Practice	Frequency
Audit dependencies for known CVEs	Every build (CI)
Pin dependency versions	Always (lockfile)
Review new dependencies before adding	Every time
Remove unused dependencies	Every release
Prefer well-maintained dependencies	>1000 stars, active maintainer, no critical CVEs

Before adding a dependency, ask: "Does this dependency have access to our users' data? What happens if it's compromised?" If the answer is scary, vendor it or find an alternative.

实践	执行频率
扫描依赖的已知CVE漏洞	每次构建（CI流程中）
锁定依赖版本	始终（用锁文件）
新增依赖前做评审	每次新增时
移除未使用的依赖	每次发版时
优先选择维护良好的依赖	Star数>1000、维护者活跃、无严重CVE漏洞的依赖

新增依赖前先问自己： “这个依赖是否能接触到我们的用户数据？如果它被攻陷了会有什么后果？”如果后果很严重，要么做vendor处理要么找替代方案。

Rule 7: Output Encoding and Injection Prevention

规则7：输出编码与注入防护

Attack	Prevention
SQL Injection	Parameterized queries ONLY. Never string concatenation.
XSS	Context-aware output encoding. CSP headers.
Command Injection	Never pass user input to shell commands. Use libraries.
Path Traversal	Validate and canonicalize file paths. Never use raw user input.
SSRF	Allowlist outbound URLs. Block internal network ranges.
Deserialization	Never deserialize untrusted data with native serializers. Use JSON.
CSRF	Anti-CSRF tokens for state-changing operations. SameSite cookies.

If user input touches a query, command, path, or URL — it MUST be parameterized or sanitized.

攻击类型	防护手段
SQL 注入	仅使用参数化查询，永远不要拼接SQL字符串
XSS	上下文感知的输出编码，配置CSP请求头
命令注入	永远不要把用户输入传给shell命令，使用封装好的库
路径遍历	校验并规范化文件路径，永远不要直接使用原始用户输入
SSRF	对外访问URL用允许名单限制，屏蔽内部网络地址段
反序列化漏洞	永远不要用原生序列化器反序列化不可信数据，使用JSON
CSRF	状态变更操作添加CSRF令牌，使用SameSite属性的Cookie

如果用户输入会接触到查询语句、命令、文件路径或者URL —— 必须做参数化处理或者sanitization校验。

Applying This Skill

规范落地方式

During Planning (brainstorming / writing-plans)

规划阶段（头脑风暴/编写方案）

During Implementation (executing-plans)

开发阶段（执行方案）

As you write code:

Use parameterized queries for ALL database access. No exceptions.
Add input validation at every API endpoint before any business logic.
Never log sensitive data (passwords, tokens, PII, credit cards).
Set security headers on every response (CSP, HSTS, X-Frame-Options).
Use crypto libraries, never roll your own encryption.
Add rate limiting to authentication endpoints.

写代码时要注意：

所有数据库访问都使用参数化查询，没有例外
所有API接口在执行业务逻辑前先做输入校验
永远不要打印敏感数据（密码、令牌、PII、信用卡信息）到日志
所有响应都添加安全请求头（CSP、HSTS、X-Frame-Options）
使用成熟的加密库，永远不要自己实现加密算法
身份认证接口添加限流配置

During Review (code-review / receiving-code-review)

评审阶段（代码评审/接收代码评审）

Verify these as part of every code review:

No hardcoded secrets or credentials
Input validation on all boundaries
Parameterized queries (no string concatenation in SQL)
Proper output encoding (no raw HTML insertion)
Auth/authz checks on every endpoint
No sensitive data in logs or error messages
Security headers present

每次代码评审都要校验以下内容：

没有硬编码的密钥或凭证
所有边界都做了输入校验
使用参数化查询（SQL中没有字符串拼接）
做了正确的输出编码（没有直接插入原始HTML）
每个接口都做了身份认证/权限授权校验
日志和错误信息中没有敏感数据
响应包含安全请求头

When Modifying Existing Code

修改现有代码时

If existing code violates these rules:

Security violations ARE required to fix if they're in code you're touching.
If you discover a hardcoded secret, flag it immediately — even in unrelated code.
If you're adding a new endpoint, it MUST have auth even if neighboring endpoints don't.
Never make security worse. If existing code has validation, don't remove it.

如果现有代码违反了这些规则：

如果你正在修改的代码存在安全违规，必须修复
如果你发现了硬编码的密钥，立刻上报 —— 哪怕是不相关的代码里的
如果你新增了接口，哪怕相邻的接口没有身份认证，你的新接口也必须加
永远不要降低安全等级。如果现有代码有校验逻辑，不要删除它

OWASP Top 10 Quick Reference

OWASP Top 10 速查表

#	Risk	Key Defense
A01	Broken Access Control	Authz checks on every operation, deny by default
A02	Cryptographic Failures	TLS everywhere, strong algorithms, no plaintext secrets
A03	Injection	Parameterized queries, input validation
A04	Insecure Design	Threat modeling during planning, not after
A05	Security Misconfiguration	Secure defaults, no default credentials
A06	Vulnerable Components	Dependency scanning, pinned versions
A07	Auth Failures	MFA, rate limiting, secure session management
A08	Data Integrity Failures	Signed updates, CI/CD security, input validation
A09	Logging Failures	Log security events, don't log secrets, monitor
A10	SSRF	Allowlist outbound URLs, block internal ranges

序号	风险	核心防御手段
A01	访问控制失效	每次操作都做权限校验，默认拒绝
A02	加密失效	全链路开启TLS，使用强加密算法，不存储明文密钥
A03	注入漏洞	使用参数化查询，做输入校验
A04	不安全设计	规划阶段做威胁建模，不要事后补
A05	安全配置错误	安全默认配置，不使用默认凭证
A06	存在漏洞的组件	依赖漏洞扫描，锁定依赖版本
A07	身份认证失效	开启MFA，接口限流，安全的会话管理
A08	数据完整性失效	签名更新，CI/CD安全防护，输入校验
A09	日志与监控失效	记录安全事件，不打印密钥，做异常监控
A10	SSRF	对外访问URL用允许名单限制，屏蔽内部地址段

Anti-Patterns

反模式

Pattern	Problem	Fix
"Security through obscurity"	Hiding ≠ protecting	Proper access controls
Trusting client-side validation	Trivially bypassed	Server-side validation always
Broad CORS ( `*` )	Any origin can access API	Explicit origin allowlist
Admin-by-default	Over-privileged users	Least privilege, role-based access
Logging everything	Secrets in logs	Structured logging with redaction
Rolling your own crypto	Guaranteed vulnerabilities	Use vetted libraries (libsodium, etc.)

反模式	问题	修复方案
“模糊式安全”	隐藏不等于保护	做完善的访问控制
只依赖客户端校验	可以轻松绕过	永远要做服务端校验
宽松CORS配置（ `*` ）	任何来源都可以访问API	明确配置允许的来源名单
默认管理员权限	用户权限过大	最小权限原则，基于角色的权限控制
不加区分打印所有日志	日志中泄露密钥	结构化日志+自动脱敏
自己实现加密算法	必然存在漏洞	使用经过验证的加密库（如libsodium等）

Rationalization Prevention

常见借口纠偏

Excuse	Reality
"It's just an internal tool"	Internal tools get compromised. Insider threats are real.
"We'll add security later"	Later never comes. Vulnerabilities ship.
"Nobody would try that"	They will. And they have automated tools.
"It's behind a firewall"	Firewalls get bypassed. Defense in depth.
"We don't have sensitive data"	User emails, passwords, and usage patterns are sensitive.
"This is just a prototype"	Prototypes become production. Secure from day one.

借口	现实
“这只是个内部工具”	内部工具也会被攻陷，内部威胁是真实存在的
“我们后面再加安全”	后面永远不会来，漏洞会直接上线
“没人会这么攻击的”	他们会的，而且还有自动化攻击工具
“它在防火墙后面”	防火墙可以被绕过，要做深度防御
“我们没有敏感数据”	用户邮箱、密码、使用行为都是敏感数据
“这只是个原型”	原型最终会变成生产代码，从第一天就做安全