security-best-practice

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Security Best Practice

安全最佳实践

You are auditing and hardening authentication code for security best practices.

你将根据安全最佳实践对认证代码进行审计和强化。

Rules

规则

Individual security rules are in the

rules/

directory, organized by impact priority. Read

rules/_sections.md

for the full taxonomy, and read individual rule files for checklists and fix patterns.

Critical Impact:

```
rules/credential-storage.md
```
— Password hashing, secret management, key handling
```
rules/error-handling.md
```
— User enumeration, timing attacks, stack trace leaks

High Impact:

```
rules/session-security.md
```
— Token generation, cookie flags, session lifecycle
```
rules/input-validation.md
```
— SQL injection, XSS, header injection, body validation

Medium Impact:

```
rules/rate-limiting.md
```
— Login throttling, account lockout, CAPTCHA triggers
```
rules/csrf-protection.md
```
— CSRF prevention for cookie-based auth

Lower Priority:

```
rules/http-security-headers.md
```
— HSTS, CSP, X-Frame-Options, Referrer-Policy

各项安全规则位于

rules/

目录下，按影响优先级排序。阅读

rules/_sections.md

获取完整分类体系，阅读单个规则文件获取检查清单和修复模式。

高影响（Critical Impact）：

```
rules/credential-storage.md
```
— 密码哈希、密钥管理、密钥处理
```
rules/error-handling.md
```
— 用户枚举、时序攻击、堆栈跟踪泄露

中高影响（High Impact）：

```
rules/session-security.md
```
— 令牌生成、Cookie标记、会话生命周期
```
rules/input-validation.md
```
— SQL注入、XSS、头部注入、请求体验证

中影响（Medium Impact）：

```
rules/rate-limiting.md
```
— 登录限流、账户锁定、CAPTCHA触发
```
rules/csrf-protection.md
```
— 基于Cookie的认证的CSRF防护

低优先级（Lower Priority）：

```
rules/http-security-headers.md
```
— HSTS、CSP、X-Frame-Options、Referrer-Policy

Step 1: Detect Project Context

步骤1：检测项目上下文

Before starting, scan the user's project to understand their stack:

Look for framework config files (

next.config.*

package.json

go.mod

Cargo.toml

pyproject.toml

build.gradle*

pom.xml

)

Look for existing auth code — route handlers for sign-up, sign-in, session, sign-out
Look for database/ORM setup and session storage
Look for existing security measures (rate limiting, CSRF tokens, CSP headers)

开始前，扫描用户的项目以了解其技术栈：

查找框架配置文件（

next.config.*

、

package.json

、

go.mod

、

Cargo.toml

、

pyproject.toml

、

build.gradle*

、

pom.xml

）

查找现有认证代码——注册、登录、会话、登出的路由处理器
查找数据库/ORM设置与会话存储
查找现有安全措施（限流、CSRF令牌、CSP头部）

Step 2: Choose Audit Scope

步骤2：选择审计范围

Use the

AskUserQuestion

tool to ask the user what they want to harden. Use multiSelect: true so they can pick multiple areas at once.

Ask "Which security areas do you want to audit and harden?" with header "Security audit scope".

Credential storage — "Password hashing, secret management, key rotation"
Session security — "Token generation, expiry, cookie flags, session fixation"
Input validation — "SQL injection, XSS, header injection, request body validation"
Rate limiting & brute-force protection — "Login throttling, account lockout, CAPTCHA triggers"
HTTP security headers — "CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy"
CSRF protection — "Cross-site request forgery prevention for cookie-based auth"
Error handling & information leakage — "Generic errors, no stack traces, no user enumeration"
Full audit (all of the above) — "Comprehensive security review"

使用

AskUserQuestion

工具询问用户想要强化的内容。设置multiSelect: true以便用户可同时选择多个领域。

以“安全审计范围”为标题，询问“你想要审计并强化哪些安全领域？”：

凭证存储 — “密码哈希、密钥管理、密钥轮换”
会话安全 — “令牌生成、过期、Cookie标记、会话固定防护”
输入验证 — “SQL注入、XSS、头部注入、请求体验证”
限流与暴力破解防护 — “登录限流、账户锁定、CAPTCHA触发”
HTTP安全头部 — “CSP、HSTS、X-Frame-Options、Referrer-Policy、Permissions-Policy”
CSRF防护 — “基于Cookie的认证的跨站请求伪造防护”
错误处理与信息泄露 — “通用错误提示、无堆栈跟踪、无用户枚举”
全面审计（以上所有） — “全面安全审查”

Step 3: Run the Audit

步骤3：执行审计

For each selected area, read the corresponding rule file from

rules/

and review the user's code against its checklist. Report findings as:

PASS — implementation is correct
FAIL — vulnerability or misconfiguration found (include file path, line number, and fix)
MISSING — security control is absent (include where to add it and sample code)

After the audit, apply fixes directly to the code. For each fix, explain what was wrong and why the fix is necessary.

对于每个选中的领域，从

rules/

中读取对应的规则文件，并对照检查清单审查用户代码。按以下格式报告结果：

PASS（通过） — 实现正确
FAIL（失败） — 发现漏洞或配置错误（包含文件路径、行号及修复方案）
MISSING（缺失） — 缺少安全控制（包含添加位置及示例代码）

审计完成后，直接对代码应用修复。对于每个修复，说明问题所在及修复的必要性。

Step 4: Generate Report

步骤4：生成报告

After applying fixes, produce a summary table:

Area	Status	Issues Found	Fixed
Credential storage	PASS/FAIL	description	Yes/No
Session security	PASS/FAIL	description	Yes/No
...	...	...	...

For any issues that cannot be auto-fixed (e.g., require infrastructure changes like adding Redis for rate limiting), list them as manual action items with clear instructions.

应用修复后，生成汇总表格：

领域	状态	发现的问题	是否已修复
凭证存储	PASS/FAIL	描述	是/否
会话安全	PASS/FAIL	描述	是/否
...	...	...	...

对于无法自动修复的问题（例如需要添加Redis用于限流等基础设施变更），将其列为手动操作项并提供明确说明。

Step 5: Verify Fixes

步骤5：验证修复

After applying fixes:

If the project has tests, run them to ensure nothing broke
If the project has a linter, run it to verify code style
If the project has a build step, run it to check for compilation errors

应用修复后：

如果项目有测试，运行测试确保未引入问题
如果项目有代码检查工具，运行它验证代码风格
如果项目有构建步骤，运行它检查编译错误

Implementation Rules

实施规则

Never weaken existing security. If the code already uses argon2, do not downgrade to bcrypt. If cookies already have
```
SameSite=Strict
```
, do not change to
```
Lax
```
.
Follow the project's existing patterns. If they use middleware for other concerns, add security middleware the same way. Match naming conventions, file structure, and error handling style.
Do not add dependencies without asking. If a fix requires a new library (e.g.,
```
helmet
```
for Express,
```
csurf
```
for CSRF), ask the user before adding it.
Adapt to the language/framework idioms. Use the canonical approach for each ecosystem (e.g.,
```
helmet
```
middleware in Express,
```
SecurityFilterChain
```
in Spring Boot, middleware in Go/Chi).
Be conservative with CSP. A too-strict Content-Security-Policy can break the application. Start with
```
default-src 'self'
```
and add exceptions based on what the app actually loads.
Respect the auth-spec project rules. All auth code must be hand-written — no auth libraries (better-auth, next-auth, Auth.js, lucia, passport, etc.). Only allowed deps: web framework, ORM, password hashing lib, and security-header/CSRF utility libs.

绝不削弱现有安全措施：如果代码已使用argon2，不要降级为bcrypt。如果Cookie已设置
```
SameSite=Strict
```
，不要改为
```
Lax
```
。
遵循项目现有模式：如果项目使用中间件处理其他事务，以相同方式添加安全中间件。匹配命名规范、文件结构和错误处理风格。
未经询问不要添加依赖：如果修复需要新库（例如Express的
```
helmet
```
、CSRF的
```
csurf
```
），先询问用户再添加。
适配语言/框架的惯用方式：针对每个生态系统使用标准方案（例如Express的
```
helmet
```
中间件、Spring Boot的
```
SecurityFilterChain
```
、Go/Chi的中间件）。
CSP设置要保守：过于严格的Content-Security-Policy可能会导致应用崩溃。从
```
default-src 'self'
```
开始，根据应用实际加载的内容添加例外。
遵守auth-spec项目规则：所有认证代码必须手写——禁止使用认证库（better-auth、next-auth、Auth.js、lucia、passport等）。仅允许以下依赖：Web框架、ORM、密码哈希库、安全头部/CSRF工具库。