security-audit

Security Audit

CI/CD catches deterministic issues (dependency vulnerabilities, hardcoded secrets), while this skill reviews issues requiring comprehension (data flow tracing, business logic security). The two are complementary, not redundant.

---

Step 1: Determine audit scope and depth

收到审计请求
  │
  ├─ 快速扫描（单模块 / 局部改动 / 敏感模块修改后）
  │   选 1-2 个最相关的维度检查
  │   产出：终端输出结果，不生成报告
  │
  └─ 完整审计（release 发版前 / 新服务首次上线 / 重大安全相关改动）
      5 个维度全量检查
      产出：docs/audits/YYYY-MM-DD-<服务名>-audit.md

Scope identification

1. Determine audit targets: Which directories/modules/services? Use AskUserQuestion to confirm, do not guess
2. Identify the tech stack: Detect package.json / requirements.txt / pyproject.toml / tsconfig.json
3. Identify sensitive areas: Prioritize reviewing the following directories and files:
   • Route definitions, middleware (authentication/authorization related)
   • Database operation layer (ORM calls, raw queries)
   • User input handling (forms, API parameter parsing)
   • Configuration files (CORS, security headers, environment variable references)
   • Modules related to payments/orders/user data

---

Step 2: Review dimension by dimension

Check one by one according to the following 5 dimensions. Each dimension requiresreading the code, not judging by impression.

Dimension 1: Injection protection

Review objective: Whether user-controllable input enters dangerous operations only after proper handling.

Checklist：

Injection type	Concern	Secure practice
SQL injection	Raw SQL concatenation, ORM raw query	Parameterized queries, prepared statements
Command injection	exec()、child_process、os.system()、subprocess	Avoid concatenating user input into commands, use argument arrays
XSS	innerHTML、dangerouslySetInnerHTML, unescaped output in templates	Output escaping, CSP headers, avoid directly inserting HTML
Path traversal	User input concatenated into file paths,../ not filtered	Path normalization, whitelist validation,path.resolve check prefix after
SSRF	User input used as URL to initiate server-side requests	URL whitelist, prohibit internal network addresses, DNS rebinding protection
Template injection	User input directly enters template engine rendering	Avoid dynamic template compilation, use a sandbox

Review method：

1. Find all user input entry points (route parameters, query, body, header, cookie)
2. Trace the data flow of each input—which dangerous function does it ultimately reach?
3. Has it gone through validation/escaping/parameterization in between?

Dimension 2: Authentication and authorization

Review objective: Ensure every resource that needs protection has correct authentication and authorization checks.

Checklist：

Check item	Concern
Authentication coverage	Are there endpoints "running naked"—should require login but do not have authentication middleware added?
Authorization granularity	Can user A access user B's data by changing the ID? (IDOR)
JWT/Session	Key strength, expiration time, refresh mechanism, whether logout actually invalidates
CORS policy	Access-Control-Allow-Origin Is it too permissive (*)? Origin checking in credentials mode
Password policy	Are passwords stored as bcrypt/argon2 hashes, is there a strength requirement
Authorization bypass	Frontend hiding ≠ backend authorization, check whether permission checks are only done on the frontend

Review method：

1. List all routes/endpoints, marking which have authentication middleware and which do not
2. Find "naked" endpoints and determine whether authentication should be added
3. Check the authorization logic: can the current user only operate on their own resources?

Dimension 3: Sensitive data handling

Review objective: Whether sensitive data is properly protected in storage, transmission, and logs.

Checklist：

Check item	Focus
Password storage	Is bcrypt/argon2 used? Is it plaintext or MD5/SHA1?
Encryption algorithm	Whether known weak algorithms are used (DES, RC4, MD5 for encryption)
Log masking	Are passwords, tokens, phone numbers, or ID numbers printed in logs
Error information	Whether exception responses leak stack traces, SQL statements, or internal paths
Data transmission	Do sensitive APIs enforce HTTPS? Are cookies set with Secure and HttpOnly
Frontend storage	Is the token stored in localStorage (can be stolen by XSS) or an httpOnly cookie?

Review method：

1. Search for password/token-related storage and comparison logic
2. Search log outputs (console.log、logger.、print), and check whether they contain sensitive fields
3. Check the error handling middleware to confirm that the production environment does not return stack trace information

Dimension 4: Configuration security

Review objective: Whether security-related configuration is reasonable and whether the production environment is hardened.

Checklist：

Check item	Focus
Security response headers	X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、CSP
Debug mode	Whether debug/verbose error output is disabled in the production environment
Default credentials	Whether there are default passwords, test accounts, admin/admin
Rate limiting	Whether interfaces such as login, registration, and verification codes have rate limits
File upload	Are file types and sizes restricted? Is the storage path outside the web-accessible directory?
Environment isolation	Are production and development configurations separated? Are environment variables referenced correctly

Dimension 5: Business security

Review objective: Identify security risks that require understanding business semantics to discover.

Checklist：

Check item	Focus
Unauthorized access (IDOR)	Whether modifying the ID/parameters in a request can access others' data
Batch enumeration	Whether usernames/emails can be enumerated (different responses for registration/login/password recovery)
Race conditions	Whether balance deduction, inventory deduction, and coupon redemption have concurrency protection
Logic bypass	Can the payment amount be tampered with on the frontend? Can process steps be skipped?
Replay attacks	Whether critical operations have idempotency protection or a nonce mechanism
Information leakage	Whether API responses return extra fields (such as other users' information, internal IDs)

Review method：

1. Think from the attacker's perspective: "If I wanted to steal data, exploit promotions, or cause damage, how would I do it?"
2. Check parameter validation and permission checks for critical business operations
3. Pay attention to cases of "frontend validation but no backend validation"

---

Step 3: Risk classification

Classify each finding according to the following standards:

Level	Standard	Handling requirement
High risk	Can directly lead to data leakage, unauthorized access, or code execution	Must be fixed before release, provide specific fix code
Medium risk	Exploitation conditions exist but the risk is controllable, or defense in depth is insufficient	Recommended to fix, provide the fix direction
Low risk	Missing best practices, low risk in the short term	Record for improvement, does not block release

Classification principles:

• When uncertain, classify higher; better overly cautious than to miss something
• But do not mark all findings as high risk—the cry-wolf effect will reduce vigilance
• Those with other existing defensive measures can be appropriately downgraded (such as XSS risk but with strict CSP already in place)

---

Step 4: Generate audit report

Full auditwhen, generate the report to docs/audits/YYYY-MM-DD-<服务名>-audit.md：

# 安全审计报告：<服务名>

## 审计概览
- 审计日期：YYYY-MM-DD
- 审计范围：<目录/模块列表>
- 技术栈：<自动识别结果>
- 风险摘要：🔴 X 高危 / 🟡 X 中危 / 🟢 X 低危

## 审计结论

**✅ 通过** / **⚠️ 有条件通过（需修复高危后上线）** / **❌ 不通过**

## 详细发现

### 1. 注入防护
（发现 / 无风险）

### 2. 认证与授权
（发现 / 无风险）

### 3. 敏感数据处理
（发现 / 无风险）

### 4. 配置安全
（发现 / 无风险）

### 5. 业务安全
（发现 / 无风险）

## 修复清单

| # | 等级 | 维度 | 问题描述 | 文件位置 | 修复建议 |
|---|------|------|---------|---------|---------|

## 历史审计
- [上次审计](链接)（如有）

Each finding must include:

• Specific code location(file:line number)
• Problem description(what it is, why it is dangerous)
• Attack scenario(how the attacker exploits it)
• Fix recommendation(provide code for high risk, direction for medium risk)

---

Step 5: Fix and re-check

1. High-risk issues: provide specific fix code, assist the user in fixing on the spot
2. Re-check after fix: after the fix is completed, re-check the corresponding dimension to confirm the fix is effective
3. Report update: mark fixed items in the fix checklist

---

Connection with other skills/processes

CI/CD 安全流水线（自动化，确定性）
  ├─ pre-commit: gitleaks 拦截敏感信息
  └─ PR Check: 依赖漏洞 + 静态规则扫描
         │
         ↓ 自动化通过后
security-audit（本 skill，AI 审查）
  ├─ task-finish 提示：涉及敏感模块时建议快速扫描
  └─ release 强制：发版前完整审计
         │
         ↓ 审计通过
release — 发版

Audit report directory：docs/audits/, naming format YYYY-MM-DD-<服务名>-audit.md

---

Notes

• Do not replace CI/CD: dependency vulnerability scanning (npm audit) and sensitive information grep (gitleaks) are matters for automated pipelines; this skill does not repeat them
• Do not over-report: only report real risks; do not list all insignificant warnings just to appear comprehensive
• Understand the business before reviewing: first use code-walkthrough Or quickly read and understand the business logic, then conduct the security review. A security review detached from the business is inefficient.
• Attacker mindset: For every dimension, ask "If I were an attacker, how would I exploit this?". A problem for which no attack path can be found is not considered high risk.