security-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Security Audit Skill

安全审计技能

When auditing code for security, follow this structured process. Treat every finding seriously — a single vulnerability can compromise an entire system.

在对代码进行安全审计时，请遵循以下结构化流程。认真对待每一个发现——单个漏洞就可能危及整个系统。

1. Secrets & Credentials

1. 密钥与凭证

Scan the entire codebase for exposed secrets:

Hardcoded API keys, tokens, passwords in source code
Secrets in config files committed to Git (.env, config.json, settings.py)
Secrets in logs — sensitive data printed in console.log, logger.info, etc.
Secrets in error messages — stack traces or error responses leaking internals
Secrets in comments — old credentials left in TODO or commented-out code
Secrets in Git history — check if secrets were committed and later removed (still in history)

Check commands:

bash

undefined

扫描整个代码库，查找暴露的密钥：

源代码中硬编码的API密钥、令牌、密码
提交到Git的配置文件中的密钥（.env、config.json、settings.py）
日志中的密钥——console.log、logger.info等打印的敏感数据
错误信息中的密钥——堆栈跟踪或错误响应泄露内部信息
注释中的密钥——留在TODO或已注释代码中的旧凭证
Git历史中的密钥——检查是否有密钥曾被提交后又删除（仍存在于历史记录中）

检查命令：

bash

undefined

Search for common secret patterns

Check for .env files committed

git ls-files | grep -i ".env"

Check git history for secrets

git log --all --diff-filter=D -- ".env" ".pem" "*.key"


Verify:
- Is a `.gitignore` in place with `.env`, `*.pem`, `*.key`, `*.p12`?
- Are secrets loaded from environment variables or a vault (not files)?
- Is there a `.env.example` with placeholder values (not real secrets)?

git log --all --diff-filter=D -- ".env" ".pem" "*.key"


验证：
- 是否存在包含.env、*.pem、*.key、*.p12的.gitignore文件？
- 密钥是否从环境变量或密钥管理库加载（而非文件）？
- 是否有包含占位符值（非真实密钥）的.env.example文件？

2. Injection Attacks

2. 注入攻击

SQL Injection

SQL注入

// 🔴 VULNERABLE — string concatenation in query
const user = await db.query(`SELECT * FROM users WHERE id = '${req.params.id}'`);

// ✅ SAFE — parameterized query
const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);

// 🔴 存在漏洞 — 查询中使用字符串拼接
const user = await db.query(`SELECT * FROM users WHERE id = '${req.params.id}'`);

// ✅ 安全写法 — 参数化查询
const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);

NoSQL Injection

NoSQL注入

// 🔴 VULNERABLE — user input directly in query object
const user = await User.find({ username: req.body.username });

// ✅ SAFE — explicitly cast to string
const user = await User.find({ username: String(req.body.username) });

// 🔴 存在漏洞 — 用户输入直接传入查询对象
const user = await User.find({ username: req.body.username });

// ✅ 安全写法 — 显式转换为字符串
const user = await User.find({ username: String(req.body.username) });

Command Injection

命令注入

// 🔴 VULNERABLE — user input in shell command
exec(`convert ${req.body.filename} output.png`);

// ✅ SAFE — use execFile with arguments array
execFile('convert', [sanitizedFilename, 'output.png']);

// 🔴 存在漏洞 — 用户输入传入shell命令
exec(`convert ${req.body.filename} output.png`);

// ✅ 安全写法 — 使用execFile并传入参数数组
execFile('convert', [sanitizedFilename, 'output.png']);

XSS (Cross-Site Scripting)

XSS（跨站脚本攻击）

// 🔴 VULNERABLE — unsanitized HTML rendering
element.innerHTML = userInput;
// React: dangerouslySetInnerHTML={{ __html: userInput }}

// ✅ SAFE — use textContent or sanitize
element.textContent = userInput;
// React: use DOMPurify.sanitize() before dangerouslySetInnerHTML

// 🔴 存在漏洞 — 未经过滤的HTML渲染
element.innerHTML = userInput;
// React: dangerouslySetInnerHTML={{ __html: userInput }}

// ✅ 安全写法 — 使用textContent或进行过滤
element.textContent = userInput;
// React: 在使用dangerouslySetInnerHTML前用DOMPurify.sanitize()处理

Path Traversal

路径遍历

// 🔴 VULNERABLE — user controls file path
const file = fs.readFileSync(`./uploads/${req.params.filename}`);

// ✅ SAFE — resolve and validate path stays within allowed directory
const safePath = path.resolve('./uploads', req.params.filename);
if (!safePath.startsWith(path.resolve('./uploads'))) throw new Error('Invalid path');

// 🔴 存在漏洞 — 用户控制文件路径
const file = fs.readFileSync(`./uploads/${req.params.filename}`);

// ✅ 安全写法 — 解析并验证路径是否在允许的目录内
const safePath = path.resolve('./uploads', req.params.filename);
if (!safePath.startsWith(path.resolve('./uploads'))) throw new Error('Invalid path');

Template Injection

模板注入

Check for user input passed directly into template engines (Jinja2, EJS, Handlebars)
Verify auto-escaping is enabled

检查用户输入是否直接传入模板引擎（Jinja2、EJS、Handlebars）
验证是否启用了自动转义

3. Authentication & Authorization

3. 认证与授权

Authentication Flaws

认证缺陷

Weak password requirements — no minimum length, complexity, or breach checking
Missing rate limiting on login endpoints (brute force risk)
Missing account lockout after failed attempts
Insecure password storage — plaintext, MD5, SHA1 (use bcrypt/argon2 with proper cost)
Missing MFA on sensitive operations
Session tokens in URLs — tokens should be in headers or httpOnly cookies
No session expiration — tokens that never expire

弱密码要求——无最小长度、复杂度或泄露检查
登录端点缺少速率限制（存在暴力破解风险）
多次失败尝试后未锁定账户
不安全的密码存储——明文、MD5、SHA1（使用bcrypt/argon2并设置合适的成本因子）
敏感操作缺少多因素认证（MFA）
会话令牌出现在URL中——令牌应放在请求头或httpOnly Cookie中
无会话过期机制——令牌永久有效

Authorization Flaws

授权缺陷

Missing authorization checks — endpoints accessible without verifying user permissions
IDOR (Insecure Direct Object Reference) — accessing other users' data by changing an ID
Privilege escalation — regular user can access admin endpoints
Missing resource ownership checks — user A can modify user B's data

// 🔴 VULNERABLE — IDOR: no ownership check
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

// ✅ SAFE — verify ownership
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (order.userId !== req.user.id) return res.status(403).json({ error: 'Forbidden' });
  res.json(order);
});

缺少授权检查——无需验证用户权限即可访问端点
IDOR（不安全的直接对象引用）——通过修改ID访问其他用户的数据
权限提升——普通用户可访问管理员端点
缺少资源所有权检查——用户A可修改用户B的数据

// 🔴 存在漏洞 — IDOR：无所有权检查
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  res.json(order);
});

// ✅ 安全写法 — 验证所有权
app.get('/api/orders/:id', async (req, res) => {
  const order = await Order.findById(req.params.id);
  if (order.userId !== req.user.id) return res.status(403).json({ error: 'Forbidden' });
  res.json(order);
});

4. Data Exposure

4. 数据暴露

Sensitive data in API responses — returning passwords, tokens, SSNs, full credit card numbers
Verbose error messages in production — stack traces, database details, internal paths
Missing field filtering — returning entire database objects instead of specific fields
Sensitive data in client-side storage — tokens in localStorage (use httpOnly cookies)
PII in logs — names, emails, IPs logged without redaction
Missing data encryption — sensitive data stored unencrypted at rest
CORS misconfiguration —
```
Access-Control-Allow-Origin: *
```
on authenticated endpoints

// 🔴 VULNERABLE — leaking sensitive fields
res.json(user);

// ✅ SAFE — explicit field selection
res.json({
  id: user.id,
  name: user.name,
  email: user.email,
});

API响应中包含敏感数据——返回密码、令牌、社保号码、完整信用卡号
生产环境中返回详细错误信息——堆栈跟踪、数据库细节、内部路径
缺少字段过滤——返回整个数据库对象而非特定字段
敏感数据存储在客户端——令牌存储在localStorage中（应使用httpOnly Cookie）
日志中包含个人可识别信息（PII）——姓名、邮箱、IP地址未脱敏即记录
敏感数据存储时未加密——静态数据未加密
CORS配置错误——认证端点设置
```
Access-Control-Allow-Origin: *
```

// 🔴 存在漏洞 — 泄露敏感字段
res.json(user);

// ✅ 安全写法 — 显式选择字段
res.json({
  id: user.id,
  name: user.name,
  email: user.email,
});

5. Input Validation

5. 输入验证

Missing validation — no checks on request body, params, query strings
Type confusion — expecting a number but accepting a string
Missing length limits — unbounded input that could cause DoS
Missing file upload validation — no checks on file type, size, or content
Regex DoS (ReDoS) — catastrophic backtracking on malicious input
Missing content-type validation — accepting unexpected content types

Verify:

Is there a validation library in use (Zod, Joi, class-validator, Pydantic)?
Are all API endpoints validating input before processing?
Are file uploads restricted by type, size, and scanned for malware?

缺少验证——未对请求体、参数、查询字符串进行检查
类型混淆——期望数字但接受字符串
缺少长度限制——无边界的输入可能导致拒绝服务（DoS）
文件上传缺少验证——未检查文件类型、大小或内容
正则表达式拒绝服务（ReDoS）——恶意输入导致灾难性回溯
缺少内容类型验证——接受意外的内容类型

验证：

是否使用了验证库（Zod、Joi、class-validator、Pydantic）？
所有API端点是否在处理前验证输入？
文件上传是否按类型、大小限制，是否扫描恶意软件？

6. Dependencies

6. 依赖项

Run these checks:

bash

undefined

执行以下检查：

bash

undefined

Node.js

npm audit

or

或

npx better-npm-audit audit

Python

pip audit

or

或

safety check

Check for outdated packages

检查过时包

npm outdated pip list --outdated


Look for:
- **Known CVEs** in dependencies
- **Outdated packages** with known vulnerabilities
- **Abandoned packages** — no updates in 2+ years
- **Typosquatting risk** — verify package names are correct
- **Excessive permissions** — packages requesting more access than needed
- **Lockfile present** — package-lock.json or yarn.lock committed

npm outdated pip list --outdated


检查内容：
- **依赖项中的已知CVE漏洞**
- **存在已知漏洞的过时包**
- **已废弃的包**——2年以上未更新
- **仿冒包风险**——验证包名是否正确
- **过度权限**——包请求的权限超出需求
- **是否存在锁定文件**——已提交package-lock.json或yarn.lock

7. HTTP Security Headers

7. HTTP安全头

Check if these headers are set:

```
Content-Security-Policy
```
— prevents XSS and data injection
```
Strict-Transport-Security
```
— enforces HTTPS
```
X-Content-Type-Options: nosniff
```
— prevents MIME type sniffing
```
X-Frame-Options: DENY
```
— prevents clickjacking
```
Referrer-Policy
```
— controls referrer information
```
Permissions-Policy
```
— restricts browser features

bash

undefined

检查是否设置了以下头：

```
Content-Security-Policy
```
——防止XSS和数据注入
```
Strict-Transport-Security
```
——强制使用HTTPS
```
X-Content-Type-Options: nosniff
```
——防止MIME类型嗅探
```
X-Frame-Options: DENY
```
——防止点击劫持
```
Referrer-Policy
```
——控制引用信息
```
Permissions-Policy
```
——限制浏览器功能

bash

undefined

Check response headers

检查响应头

curl -I https://your-app.com

undefined

curl -I https://your-app.com

undefined

8. Cryptography

8. 加密技术

Weak hashing — MD5 or SHA1 for passwords (use bcrypt, scrypt, or argon2)
Weak encryption — DES, RC4, ECB mode (use AES-256-GCM)
Hardcoded encryption keys — keys should be in environment variables or a vault
Missing TLS — HTTP connections for sensitive data
Weak JWT — using
```
alg: none
```
or HS256 with a short secret
Predictable random values — using Math.random() for tokens (use crypto.randomBytes)

// 🔴 VULNERABLE — predictable token
const token = Math.random().toString(36);

// ✅ SAFE — cryptographically secure
const token = crypto.randomBytes(32).toString('hex');

弱哈希算法——使用MD5或SHA1存储密码（使用bcrypt、scrypt或argon2）
弱加密算法——DES、RC4、ECB模式（使用AES-256-GCM）
硬编码加密密钥——密钥应存储在环境变量或密钥管理库中
缺少TLS——敏感数据使用HTTP传输
弱JWT配置——使用
```
alg: none
```
或HS256且密钥过短
可预测的随机值——使用Math.random()生成令牌（应使用crypto.randomBytes）

// 🔴 存在漏洞 — 可预测的令牌
const token = Math.random().toString(36);

// ✅ 安全写法 — 加密安全的随机值
const token = crypto.randomBytes(32).toString('hex');

9. Infrastructure & Configuration

9. 基础设施与配置

Debug mode in production — verbose errors, stack traces, debug endpoints
Default credentials — admin/admin, root/root still active
Unnecessary ports open — database ports exposed to the internet
Missing rate limiting — no protection against DoS
Missing request size limits — large payloads causing OOM
Insecure CORS — wildcard origins on authenticated endpoints
Missing CSRF protection — state-changing endpoints without CSRF tokens

生产环境中启用调试模式——详细错误信息、堆栈跟踪、调试端点
默认凭证未修改——仍使用admin/admin、root/root等默认账号
不必要的端口开放——数据库端口暴露在公网
缺少速率限制——无DoS防护
缺少请求大小限制——大负载导致内存不足（OOM）
不安全的CORS配置——认证端点使用通配符来源
缺少CSRF防护——状态变更端点无CSRF令牌

10. Stack-Specific Checks

10. 特定栈检查

Node.js / Express

Verify helmet middleware is installed and configured
Check express.json() has a size limit:
```
express.json({ limit: '10kb' })
```
Verify cookie settings: httpOnly, secure, sameSite
Check for prototype pollution in object merging (lodash.merge, Object.assign with user input)
Verify child_process calls sanitize all inputs
Check that express-rate-limit is applied to auth endpoints
Look for event emitter memory leaks (missing removeListener)
Verify no use of
```
eval()
```
,
```
Function()
```
, or
```
vm.runInNewContext()
```
with user input

验证是否安装并配置了helmet中间件
检查express.json()是否设置了大小限制：
```
express.json({ limit: '10kb' })
```
验证Cookie设置：httpOnly、secure、sameSite
检查对象合并时的原型污染（lodash.merge、Object.assign处理用户输入）
验证child_process调用是否过滤了所有输入
检查express-rate-limit是否应用于认证端点
查找事件监听器内存泄漏（未调用removeListener）
验证未使用
```
eval()
```
、
```
Function()
```
或
```
vm.runInNewContext()
```
处理用户输入

Python / Django

Verify
```
DEBUG = False
```
in production settings
Check
```
ALLOWED_HOSTS
```
is not
```
['*']
```
Verify CSRF middleware is enabled
Check for raw SQL queries without parameterization
Verify
```
SECRET_KEY
```
is loaded from environment, not hardcoded
Check for pickle deserialization of user input (RCE risk)
Verify django-cors-headers is configured with specific origins
Check that
```
@login_required
```
or permission classes are on all protected views
Look for unsafe YAML loading (
```
yaml.load()
```
without
```
Loader=SafeLoader
```
)

Verify

SECURE_SSL_REDIRECT

SESSION_COOKIE_SECURE

CSRF_COOKIE_SECURE

are True in production

验证生产环境设置中
```
DEBUG = False
```
检查
```
ALLOWED_HOSTS
```
是否未设置为
```
['*']
```
验证是否启用了CSRF中间件
检查是否存在未参数化的原生SQL查询
验证
```
SECRET_KEY
```
是否从环境变量加载，而非硬编码
检查是否存在反序列化用户输入的pickle操作（存在远程代码执行风险）
验证django-cors-headers是否配置了特定来源
检查所有受保护视图是否添加了
```
@login_required
```
或权限类
查找不安全的YAML加载（
```
yaml.load()
```
未使用
```
Loader=SafeLoader
```
）

验证生产环境中

SECURE_SSL_REDIRECT

、

SESSION_COOKIE_SECURE

、

CSRF_COOKIE_SECURE

是否设为True

Python / Flask

Verify
```
app.secret_key
```
is not hardcoded
Check for missing
```
@login_required
```
decorators on protected routes
Verify Jinja2 auto-escaping is enabled (default in Flask, but check custom templates)
Check that
```
flask-talisman
```
or similar is used for security headers
Verify
```
flask-limiter
```
is applied to auth and sensitive endpoints
Check for unsafe file uploads (missing
```
secure_filename()
```
from werkzeug)

验证
```
app.secret_key
```
未硬编码
检查受保护路由是否缺少
```
@login_required
```
装饰器
验证Jinja2自动转义是否启用（Flask默认启用，但需检查自定义模板）
检查是否使用了flask-talisman或类似工具设置安全头
验证flask-limiter是否应用于认证和敏感端点
检查文件上传是否不安全（未使用werkzeug的
```
secure_filename()
```
）

React / Next.js

Check for
```
dangerouslySetInnerHTML
```
with unsanitized input
Verify no tokens stored in localStorage (use httpOnly cookies)
Check for sensitive data in client-side code or bundle
Verify environment variables use
```
NEXT_PUBLIC_
```
prefix only for non-sensitive values
Check for open redirects in URL parameters
Verify API routes have proper authentication middleware
Check that Server Actions validate input and check authorization
Look for sensitive data in
```
getServerSideProps
```
that leaks to
```
pageProps
```
Verify
```
next.config.js
```
has proper security headers configured
Check for exposed source maps in production

检查是否使用
```
dangerouslySetInnerHTML
```
处理未过滤的用户输入
验证令牌未存储在localStorage中（使用httpOnly Cookie）
检查客户端代码或打包文件中是否包含敏感数据
验证环境变量仅对非敏感值使用
```
NEXT_PUBLIC_
```
前缀
检查URL参数中是否存在开放重定向
验证API路由是否有适当的认证中间件
检查Server Actions是否验证输入并检查授权
查找
```
getServerSideProps
```
中泄露到
```
pageProps
```
的敏感数据
验证
```
next.config.js
```
是否配置了适当的安全头
检查生产环境中是否暴露了源映射

Vue / Nuxt

Check for
```
v-html
```
with unsanitized user input
Verify no tokens stored in localStorage
Check
```
nuxt.config
```
for exposed runtime config secrets
Verify server middleware has authentication checks
Check for sensitive data leaking from server to client via
```
useAsyncData
```
or
```
useFetch
```

检查是否使用
```
v-html
```
处理未过滤的用户输入
验证令牌未存储在localStorage中
检查
```
nuxt.config
```
中是否暴露了运行时配置密钥
验证服务器中间件是否有认证检查
查找从服务器通过
```
useAsyncData
```
或
```
useFetch
```
泄露到客户端的敏感数据

Ruby on Rails

Verify
```
config.force_ssl = true
```
in production
Check for
```
html_safe
```
or
```
raw
```
on user-supplied content
Verify
```
protect_from_forgery
```
is enabled
Check for mass assignment vulnerabilities (missing
```
strong_parameters
```
)
Verify
```
has_secure_password
```
uses bcrypt
Check for unsafe
```
send()
```
or
```
constantize()
```
with user input
Verify
```
config.filter_parameters
```
includes sensitive fields

验证生产环境中
```
config.force_ssl = true
```
检查是否对用户提供的内容使用
```
html_safe
```
或
```
raw
```
验证是否启用了
```
protect_from_forgery
```
检查是否存在批量赋值漏洞（缺少
```
strong_parameters
```
）
验证
```
has_secure_password
```
是否使用bcrypt
检查是否使用
```
send()
```
或
```
constantize()
```
处理用户输入
验证
```
config.filter_parameters
```
是否包含敏感字段

Go

Check for SQL injection in
```
fmt.Sprintf
```
used in queries (use parameterized queries)
Verify TLS configuration uses minimum TLS 1.2
Check for path traversal in
```
http.ServeFile
```
or
```
os.Open
```
Verify proper error handling (no sensitive data in error responses)
Check for race conditions on shared state (missing mutex)
Verify
```
crypto/rand
```
is used instead of
```
math/rand
```
for security-sensitive values
Check for unchecked type assertions that could cause panics

检查是否在查询中使用
```
fmt.Sprintf
```
导致SQL注入（使用参数化查询）
验证TLS配置是否使用最低TLS 1.2版本
检查
```
http.ServeFile
```
或
```
os.Open
```
是否存在路径遍历风险
验证错误处理是否得当（错误响应中无敏感数据）
检查共享状态是否存在竞争条件（未使用互斥锁）
验证安全敏感值是否使用
```
crypto/rand
```
而非
```
math/rand
```
检查是否存在未检查的类型断言可能导致程序崩溃

Java / Spring Boot

Verify Spring Security is configured and not using
```
permitAll()
```
on sensitive endpoints
Check for SQL injection in
```
@Query
```
annotations with string concatenation
Verify CSRF protection is enabled (default in Spring Security)
Check for deserialization vulnerabilities (Jackson, Java serialization)
Verify
```
@Valid
```
annotation is present on request body parameters
Check for hardcoded credentials in
```
application.properties
```
or
```
application.yml
```
Verify actuator endpoints are secured and not exposed publicly
Check for Log4j/Log4Shell vulnerability in dependencies

验证Spring Security是否配置正确，敏感端点未使用
```
permitAll()
```
检查
```
@Query
```
注解中是否存在字符串拼接导致的SQL注入
验证是否启用了CSRF防护（Spring Security默认启用）
检查是否存在反序列化漏洞（Jackson、Java序列化）
验证请求体参数是否添加了
```
@Valid
```
注解
检查
```
application.properties
```
或
```
application.yml
```
中是否有硬编码凭证
验证Actuator端点是否已安全配置，未公开暴露
检查依赖项中是否存在Log4j/Log4Shell漏洞

PHP / Laravel

Verify
```
APP_DEBUG=false
```
in production
```
.env
```
Check for raw SQL queries without parameter binding
Verify CSRF middleware is applied to all POST/PUT/DELETE routes
Check for
```
eval()
```
,
```
exec()
```
,
```
system()
```
with user input
Verify file uploads use validation rules (mimes, max size)
Check that
```
Auth::check()
```
or middleware guards protect sensitive routes
Verify
```
mass assignment
```
protection via
```
$fillable
```
or
```
$guarded
```
Check for unsafe blade rendering with
```
{!! !!}
```
on user input

验证生产环境
```
.env
```
中
```
APP_DEBUG=false
```
检查是否存在未参数化的原生SQL查询
验证CSRF中间件是否应用于所有POST/PUT/DELETE路由
检查是否使用
```
eval()
```
、
```
exec()
```
、
```
system()
```
处理用户输入
验证文件上传是否使用了验证规则（mimes、max size）
检查敏感路由是否受
```
Auth::check()
```
或中间件防护
验证是否通过
```
$fillable
```
或
```
$guarded
```
进行批量赋值保护
检查是否使用
```
{!! !!}
```
渲染用户输入（不安全的Blade渲染）

Mobile (React Native / Flutter)

移动端（React Native / Flutter）

Check for sensitive data stored in AsyncStorage/SharedPreferences (use encrypted storage)
Verify API keys are not embedded in the app bundle
Check for certificate pinning on sensitive API calls
Verify deep link handlers validate input before navigation
Check for sensitive data in app logs (visible via adb logcat / Console.app)
Verify biometric authentication properly validates server-side
Check for insecure WebView configurations (JavaScript enabled with untrusted content)

检查敏感数据是否存储在AsyncStorage/SharedPreferences中（使用加密存储）
验证API密钥是否未嵌入应用包中
检查敏感API调用是否启用了证书锁定
验证深度链接处理程序是否在导航前验证输入
检查应用日志中是否包含敏感数据（可通过adb logcat / Console.app查看）
验证生物识别认证是否在服务端进行了正确验证
检查WebView配置是否不安全（对不可信内容启用了JavaScript）

Payment Security

支付安全

Verify PCI DSS compliance requirements are met
Check that full credit card numbers are never stored or logged
Verify payment processing uses tokenization
Check that webhook endpoints validate signatures
Verify refund endpoints have proper authorization and rate limiting
Check that payment amounts are validated server-side (not trusted from client)
Verify payment confirmation pages don't expose transaction details in URLs
Check for race conditions in payment processing (double-charge risk)

验证是否符合PCI DSS合规要求
检查是否从未存储或记录完整信用卡号
验证支付处理是否使用令牌化
检查Webhook端点是否验证签名
验证退款端点是否有适当的授权和速率限制
检查支付金额是否在服务端验证（不信任客户端传入的值）
验证支付确认页面是否未在URL中暴露交易详情
检查支付处理是否存在竞争条件（重复扣费风险）

AWS / Cloud Infrastructure

AWS / 云基础设施

Check for overly permissive IAM policies (
```
"Action": "*"
```
,
```
"Resource": "*"
```
)
Verify S3 buckets are not publicly accessible
Check for unencrypted RDS instances or EBS volumes
Verify security groups don't allow 0.0.0.0/0 on sensitive ports
Check for hardcoded AWS credentials (use IAM roles instead)
Verify CloudTrail logging is enabled
Check for publicly accessible EC2 instances with sensitive services
Verify secrets are stored in AWS Secrets Manager or Parameter Store

检查是否存在过度宽松的IAM策略（
```
"Action": "*"
```
、
```
"Resource": "*"
```
）
验证S3存储桶是否未公开访问
检查RDS实例或EBS卷是否未加密
验证安全组是否未在敏感端口允许0.0.0.0/0访问
检查是否存在硬编码的AWS凭证（使用IAM角色替代）
验证是否启用了CloudTrail日志
检查是否存在暴露敏感服务的公网EC2实例
验证密钥是否存储在AWS Secrets Manager或Parameter Store中

Docker / Containers

Docker / 容器

Check for containers running as root
Verify base images are from trusted sources and pinned to specific versions
Check for secrets baked into Docker images (use build secrets or runtime env)
Verify
```
.dockerignore
```
excludes
```
.env
```
,
```
.git
```
,
```
node_modules
```
Check for unnecessary packages installed in production images
Verify health checks are configured
Check for exposed ports that shouldn't be public

检查容器是否以root用户运行
验证基础镜像是否来自可信源并固定到特定版本
检查Docker镜像中是否包含密钥（使用构建密钥或运行时环境变量）
验证
```
.dockerignore
```
是否排除了.env、.git、node_modules
检查生产镜像中是否安装了不必要的包
验证是否配置了健康检查
检查是否暴露了不应公开的端口

Output Format

输出格式

For each vulnerability found:

[SEVERITY] Category — File:Line

Vulnerability: What the issue is
Risk: What an attacker could do with this
Proof: How to exploit it (for internal team understanding)
Fix: Exact code change to resolve it
Reference: CWE or OWASP link if applicable

// vulnerable code
...

// fixed code
...

Severity levels:

🔴 CRITICAL — Actively exploitable. Data breach, RCE, or full system compromise. Fix immediately.
🟠 HIGH — Exploitable with some effort. Significant data exposure or privilege escalation. Fix before next deploy.
🟡 MEDIUM — Requires specific conditions to exploit. Fix within current sprint.
🟢 LOW — Minor issue or defense-in-depth improvement. Fix when convenient.

对于每个发现的漏洞：

[严重级别] 类别 — 文件:行号

漏洞: 问题描述
风险: 攻击者可利用此漏洞进行的操作
验证: 如何利用（供内部团队理解）
修复: 解决问题的具体代码变更
参考: 适用的CWE或OWASP链接

// 存在漏洞的代码
...

// 修复后的代码
...

严重级别：

🔴 CRITICAL（严重） — 可被主动利用。可能导致数据泄露、远程代码执行或系统完全沦陷。立即修复。
🟠 HIGH（高） — 需一定手段可利用。可能导致严重数据暴露或权限提升。下次部署前修复。
🟡 MEDIUM（中） — 需特定条件才可利用。当前迭代内修复。
🟢 LOW（低） — 小问题或深度防御改进。方便时修复。

Summary

总结

End every audit with:

Risk rating — Overall security posture (Critical / High / Medium / Low risk)
Critical findings count — Number of issues that need immediate attention
Top 3 most dangerous issues — Ranked by exploitability and impact
Quick wins — Fixes that take <30 minutes and significantly reduce risk
Recommendations — Longer-term improvements (WAF, security headers, dependency scanning in CI, etc.)
What's done well — Security practices already in place that should be maintained

每次审计结束时需包含：

风险评级 — 整体安全态势（严重/高/中/低风险）
严重发现数量 — 需要立即关注的问题数量
Top 3最危险问题 — 按可利用性和影响排序
快速修复项 — 耗时<30分钟且能显著降低风险的修复
建议 — 长期改进方案（WAF、安全头、CI中加入依赖扫描等）
现有优秀实践 — 已采用的需保持的安全措施