security-pattern-check
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSecurity Pattern Check
安全模式检查
Identify security vulnerabilities and anti-patterns in code, providing immediate feedback on security issues.
识别代码中的安全漏洞与反模式,针对安全问题提供即时反馈。
Security Issue Categories
安全问题类别
1. Injection Vulnerabilities
1. 注入漏洞
- SQL Injection: Unparameterized queries with user input
- NoSQL Injection: Unsanitized MongoDB queries
- Command Injection: Shell commands with user input
- LDAP Injection: Unescaped LDAP queries
- XPath Injection: Dynamic XPath expressions
- SQL Injection:包含用户输入的未参数化查询
- NoSQL Injection:未经过滤的MongoDB查询
- Command Injection:包含用户输入的Shell命令
- LDAP Injection:未转义的LDAP查询
- XPath Injection:动态XPath表达式
2. Authentication & Authorization
2. 身份验证与授权
- Missing Authentication: Unprotected endpoints
- Weak Passwords: No password strength requirements
- Hardcoded Credentials: Passwords/keys in code
- Insecure Password Storage: Plaintext or weak hashing (MD5, SHA1)
- Missing Authorization: No permission checks
- Broken Access Control: Users accessing resources they shouldn't
- 缺失身份验证:未受保护的端点
- 弱密码:无密码强度要求
- 硬编码凭据:代码中包含密码/密钥
- 不安全的密码存储:明文存储或使用弱哈希算法(MD5、SHA1)
- 缺失授权:无权限检查
- 访问控制失效:用户可访问其无权查看的资源
3. Sensitive Data Exposure
3. 敏感数据暴露
- Logging Sensitive Data: Passwords, tokens in logs
- Insecure Storage: Unencrypted sensitive data
- Missing Encryption: No TLS/SSL
- Weak Encryption: DES, RC4, custom crypto
- Exposed Secrets: API keys, tokens in code/config
- Information Disclosure: Stack traces, verbose errors to users
- 记录敏感数据:日志中包含密码、令牌
- 不安全存储:未加密的敏感数据
- 缺失加密:未使用TLS/SSL
- 弱加密:使用DES、RC4或自定义加密算法
- 密钥暴露:代码/配置中包含API密钥、令牌
- 信息泄露:向用户返回堆栈跟踪、详细错误信息
4. Cross-Site Scripting (XSS)
4. 跨站脚本攻击(XSS)
- Reflected XSS: Echoing user input in HTML
- Stored XSS: Saving unsanitized input to database
- DOM XSS: Client-side script injection
- Missing Output Encoding: Not escaping HTML/JavaScript
- 反射型XSS:在HTML中直接回显用户输入
- 存储型XSS:将未过滤的输入保存到数据库
- DOM型XSS:客户端脚本注入
- 缺失输出编码:未对HTML/JavaScript进行转义
5. Cross-Site Request Forgery (CSRF)
5. 跨站请求伪造(CSRF)
- Missing CSRF Tokens: State-changing requests without tokens
- Incorrect Token Validation: Weak or missing validation
- GET for State Changes: Using GET for mutations
- 缺失CSRF令牌:状态变更请求未携带令牌
- 令牌验证错误:验证机制薄弱或缺失
- 使用GET请求进行状态变更:用GET请求执行修改操作
6. Security Misconfiguration
6. 安全配置错误
- Debug Mode in Production: Verbose error messages
- Default Credentials: Using default admin/admin
- Unnecessary Services: Unused endpoints or features enabled
- Missing Security Headers: No CSP, X-Frame-Options, etc.
- Directory Listing: Exposing file structure
- Improper Error Handling: Revealing system details
- 生产环境启用调试模式:返回详细错误信息
- 默认凭据:使用默认的admin/admin等凭据
- 不必要的服务:启用未使用的端点或功能
- 缺失安全头:未配置CSP、X-Frame-Options等
- 目录列表暴露:泄露文件结构
- 错误处理不当:暴露系统细节
7. Cryptographic Issues
7. 加密相关问题
- Weak Random Number Generation: Math.random() for security
- Insufficient Key Length: Short encryption keys
- Weak Hash Functions: MD5, SHA1 for security purposes
- ECB Mode: Using ECB instead of CBC/GCM
- No Salt: Password hashing without salt
- Predictable Tokens: Sequential or guessable tokens
- 弱随机数生成:使用Math.random()用于安全场景
- 密钥长度不足:加密密钥过短
- 弱哈希函数:将MD5、SHA1用于安全场景
- ECB模式:使用ECB模式而非CBC/GCM模式
- 无盐值:密码哈希未使用盐值
- 可预测令牌:使用顺序或可猜测的令牌
8. API Security
8. API安全
- Missing Rate Limiting: No protection against abuse
- Excessive Data Exposure: Returning more data than needed
- Missing Input Validation: Not validating request parameters
- Improper Assets Management: Exposing old/unused endpoints
- Security Misconfiguration: CORS allowing any origin
- 缺失速率限制:无滥用防护机制
- 过度数据暴露:返回超出需求的数据
- 缺失输入验证:未验证请求参数
- 资产管理不当:暴露旧的/未使用的端点
- 安全配置错误:CORS允许任意源访问
9. Component Vulnerabilities
9. 组件漏洞
- Known Vulnerable Dependencies: Using libraries with CVEs
- Outdated Packages: Using old versions with known issues
- Unverified Dependencies: Not checking package integrity
- 已知存在漏洞的依赖:使用包含CVE漏洞的库
- 过时包:使用存在已知问题的旧版本包
- 未验证依赖:未检查包的完整性
10. File & Resource Issues
10. 文件与资源问题
- Path Traversal: User-controlled file paths
- Unrestricted File Upload: No validation on uploads
- XML External Entity (XXE): Parsing untrusted XML
- Insecure Deserialization: Deserializing untrusted data
- Resource Exhaustion: No limits on resource usage
- 路径遍历:用户可控制文件路径
- 无限制文件上传:对上传文件无验证
- XML外部实体(XXE):解析不可信的XML
- 不安全反序列化:对不可信数据进行反序列化
- 资源耗尽:未限制资源使用量
Analysis Process
分析流程
- Identify input points - Find user input, external data
- Trace data flow - Follow data through application
- Check validation - Verify input sanitization
- Review auth/authz - Check access controls
- Examine crypto - Review encryption usage
- Scan dependencies - Check for known CVEs
- Assess configuration - Review security settings
- Generate report - Prioritize by risk
- 识别输入点 - 找出用户输入、外部数据
- 追踪数据流 - 跟踪数据在应用中的流转
- 检查验证机制 - 验证输入是否经过过滤
- 审核身份验证与授权 - 检查访问控制
- 检查加密实现 - 审核加密算法的使用
- 扫描依赖项 - 检查已知CVE漏洞
- 评估配置 - 审核安全设置
- 生成报告 - 按风险优先级排序
Return Value
返回值
Return object:
json
{
"file": "api/auth.js",
"securityScore": 6.5,
"riskLevel": "high",
"vulnerabilities": [
{
"type": "SQL Injection",
"severity": "critical",
"cwe": "CWE-89",
"owasp": "A03:2021 – Injection",
"location": {
"line": 34,
"function": "loginUser"
},
"description": "User input directly interpolated into SQL query",
"risk": {
"confidentiality": "high",
"integrity": "high",
"availability": "medium",
"exploitability": "easy"
},
"exploitScenario": "Attacker can bypass authentication or extract database contents",
"codeExample": "// Current vulnerable code...",
"fix": {
"approach": "Use parameterized queries",
"codeExample": "// Secure version...",
"effort": "small"
},
"references": [
"https://owasp.org/www-community/attacks/SQL_Injection",
"https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"
]
}
],
"recommendations": [
"Implement parameterized queries for all database access",
"Add input validation middleware",
"Enable security headers (CSP, X-Frame-Options)",
"Rotate and secure API keys using environment variables"
],
"compliance": {
"owasp": ["A03:2021", "A07:2021"],
"pciDss": ["6.5.1"],
"cwe": ["CWE-89", "CWE-798"]
}
}返回对象:
json
{
"file": "api/auth.js",
"securityScore": 6.5,
"riskLevel": "high",
"vulnerabilities": [
{
"type": "SQL Injection",
"severity": "critical",
"cwe": "CWE-89",
"owasp": "A03:2021 – Injection",
"location": {
"line": 34,
"function": "loginUser"
},
"description": "User input directly interpolated into SQL query",
"risk": {
"confidentiality": "high",
"integrity": "high",
"availability": "medium",
"exploitability": "easy"
},
"exploitScenario": "Attacker can bypass authentication or extract database contents",
"codeExample": "// Current vulnerable code...",
"fix": {
"approach": "Use parameterized queries",
"codeExample": "// Secure version...",
"effort": "small"
},
"references": [
"https://owasp.org/www-community/attacks/SQL_Injection",
"https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"
]
}
],
"recommendations": [
"Implement parameterized queries for all database access",
"Add input validation middleware",
"Enable security headers (CSP, X-Frame-Options)",
"Rotate and secure API keys using environment variables"
],
"compliance": {
"owasp": ["A03:2021", "A07:2021"],
"pciDss": ["6.5.1"],
"cwe": ["CWE-89", "CWE-798"]
}
}Examples
示例
Example 1: SQL Injection Detection
示例1:SQL Injection检测
Context: User has login function with string concatenation
Autonomous Invocation: Skill detects vulnerability:
🚨 CRITICAL SECURITY VULNERABILITY DETECTED: SQL Injection
Location: api/auth.js, line 34
Vulnerable Code:
async function loginUser(username, password) {
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
const user = await db.query(query);
return user;
}
Vulnerability: SQL Injection (CWE-89, OWASP A03:2021)
Risk Assessment:
- Severity: CRITICAL
- Exploitability: Easy (no special tools needed)
- Impact: Complete database compromise
Attack Scenario:
An attacker could input:
username: admin' --
password: anything
Resulting query:
SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'
The '--' comments out the rest, bypassing password check!
Worse attack:
username: admin'; DROP TABLE users; --
password: anything
This could DELETE YOUR ENTIRE USERS TABLE!
Secure Fix (Parameterized Query):
async function loginUser(username, password) {
// Use parameterized query (prevents injection)
const query = 'SELECT * FROM users WHERE username = ? AND password = ?';
const user = await db.query(query, [username, password]);
return user;
}
Additional Security Measures:
1. Hash passwords (never store plaintext)
- Use bcrypt, scrypt, or Argon2
- Example: const hashedPassword = await bcrypt.hash(password, 10);
2. Add rate limiting to prevent brute force
- Limit login attempts per IP
- Add exponential backoff after failures
3. Use prepared statements consistently across all queries
4. Implement logging for failed login attempts
5. Consider multi-factor authentication
References:
- OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
- SQL Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Estimated effort to fix: 30 minutes
Priority: FIX IMMEDIATELY (before deploying to production)场景:用户的登录函数使用字符串拼接
自动检测结果:技能识别到漏洞:
🚨 严重安全漏洞检测到:SQL Injection
位置:api/auth.js,第34行
漏洞代码:
async function loginUser(username, password) {
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
const user = await db.query(query);
return user;
}
漏洞类型:SQL Injection(CWE-89,OWASP A03:2021)
风险评估:
- 严重程度:CRITICAL(极高)
- 可利用性:简单(无需特殊工具)
- 影响:数据库完全泄露
攻击场景:
攻击者可输入:
username: admin' --
password: anything
生成的查询语句:
SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'
'--'会注释掉后续内容,绕过密码验证!
更严重的攻击:
username: admin'; DROP TABLE users; --
password: anything
这可能会删除你的整个用户表!
安全修复方案(参数化查询):
async function loginUser(username, password) {
// 使用参数化查询(防止注入)
const query = 'SELECT * FROM users WHERE username = ? AND password = ?';
const user = await db.query(query, [username, password]);
return user;
}
额外安全措施:
1. 对密码进行哈希处理(绝不存储明文)
- 使用bcrypt、scrypt或Argon2
- 示例:const hashedPassword = await bcrypt.hash(password, 10);
2. 添加速率限制以防止暴力破解
- 限制每个IP的登录尝试次数
- 失败后添加指数退避机制
3. 所有查询统一使用预编译语句
4. 记录失败的登录尝试
5. 考虑启用多因素身份验证
参考链接:
- OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
- SQL Injection Prevention: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
修复预估耗时:30分钟
优先级:立即修复(部署到生产环境前完成)Example 2: Hardcoded Secrets
示例2:硬编码密钥
Context: User has API key directly in code
Autonomous Invocation: Skill identifies exposure:
🚨 SECURITY ISSUE DETECTED: Hardcoded Secrets
Location: services/payment.js, line 12
Vulnerable Code:
const STRIPE_API_KEY = 'sk_live_51HqK2bL4z8pQxYz...';
const stripe = require('stripe')(STRIPE_API_KEY);
Problem: Exposed Credentials (CWE-798)
Risks:
1. API key visible in version control history (git)
2. Exposed to anyone with code access
3. Cannot rotate key without code change
4. May be accidentally shared (screenshots, pairing, etc.)
5. If key is compromised, attacker can make payments with your account
This is a LIVE API key - production payments are at risk!
Secure Fix:
1. Remove key from code immediately:
git rm --cached services/payment.js
git commit -m "Remove hardcoded API key"
2. Rotate the compromised key in Stripe dashboard
- Generate new key
- Revoke old key
3. Use environment variables:
// .env file (add to .gitignore!)
STRIPE_API_KEY=sk_live_51HqK2bL4z8pQxYz...
// services/payment.js
const stripe = require('stripe')(process.env.STRIPE_API_KEY);
4. For production, use secret management:
- AWS Secrets Manager
- Azure Key Vault
- HashiCorp Vault
- Kubernetes Secrets
5. Add to .gitignore:
.env
.env.local
.env.*.local
6. Create .env.example (without real values):
STRIPE_API_KEY=your_stripe_key_here
Best Practices:
- Never commit secrets to git
- Use different keys for dev/staging/prod
- Rotate keys regularly
- Monitor key usage for anomalies
- Use secret scanning tools (git-secrets, truffleHog)
Immediate Actions:
1. ❗ Rotate Stripe API key NOW
2. ❗ Move to environment variables
3. ❗ Check git history for other exposed secrets
4. ❗ Review access logs for suspicious activity
Estimated effort: 15 minutes
Priority: CRITICAL - Fix immediately场景:用户在代码中直接写入API密钥
自动检测结果:技能识别到暴露风险:
🚨 安全问题检测到:硬编码密钥
位置:services/payment.js,第12行
漏洞代码:
const STRIPE_API_KEY = 'sk_live_51HqK2bL4z8pQxYz...';
const stripe = require('stripe')(STRIPE_API_KEY);
问题:凭据暴露(CWE-798)
风险:
1. API密钥会出现在版本控制历史中(git)
2. 任何拥有代码访问权限的人都能看到
3. 无法在不修改代码的情况下轮换密钥
4. 可能会被意外分享(截图、配对编程等场景)
5. 如果密钥泄露,攻击者可使用你的账户进行支付
这是一个生产环境API密钥 - 生产支付存在风险!
安全修复方案:
1. 立即从代码中移除密钥:
git rm --cached services/payment.js
git commit -m "Remove hardcoded API key"
2. 在Stripe控制台轮换泄露的密钥
- 生成新密钥
- 撤销旧密钥
3. 使用环境变量:
// .env文件(添加到.gitignore!)
STRIPE_API_KEY=sk_live_51HqK2bL4z8pQxYz...
// services/payment.js
const stripe = require('stripe')(process.env.STRIPE_API_KEY);
4. 生产环境使用密钥管理工具:
- AWS Secrets Manager
- Azure Key Vault
- HashiCorp Vault
- Kubernetes Secrets
5. 添加到.gitignore:
.env
.env.local
.env.*.local
6. 创建.env.example(不含真实值):
STRIPE_API_KEY=your_stripe_key_here
最佳实践:
- 绝不要将密钥提交到git
- 开发/预发布/生产环境使用不同密钥
- 定期轮换密钥
- 监控密钥使用异常
- 使用密钥扫描工具(git-secrets、truffleHog)
立即行动:
1. ❗ 立即轮换Stripe API密钥
2. ❗ 迁移到环境变量管理
3. ❗ 检查git历史中是否有其他暴露的密钥
4. ❗ 审查访问日志是否存在可疑活动
修复预估耗时:15分钟
优先级:CRITICAL(极高)- 立即修复Example 3: Missing Input Validation
示例3:缺失输入验证
Context: User has API endpoint accepting user input
Autonomous Invocation: Skill identifies missing validation:
⚠️ SECURITY ISSUE DETECTED: Missing Input Validation
Location: api/users.js, line 45
Vulnerable Code:
app.post('/api/users', async (req, res) => {
const { username, email, age } = req.body;
const user = await db.createUser({ username, email, age });
res.json(user);
});
Problems:
1. No validation on input types
2. No length limits
3. No format validation (email)
4. No sanitization (XSS risk)
Risk: Moderate to High
- Data integrity issues
- Potential for XSS
- Database errors from unexpected input
- Business logic bypass
Attack Scenarios:
1. Type Confusion:
POST { "age": "definitely not a number" }
Could cause database errors or logic bugs
2. Extremely Long Input:
POST { "username": "A".repeat(1000000) }
Could cause memory issues or DoS
3. XSS Injection:
POST { "username": "<script>alert('xss')</script>" }
If username is displayed in HTML, executes JavaScript
4. Email Format:
POST { "email": "not-an-email" }
Breaks email functionality
Secure Fix:
// Option 1: Manual validation
app.post('/api/users', async (req, res) => {
const { username, email, age } = req.body;
// Validate types
if (typeof username !== 'string' || typeof email !== 'string') {
return res.status(400).json({ error: 'Invalid input types' });
}
// Validate lengths
if (username.length < 3 || username.length > 50) {
return res.status(400).json({ error: 'Username must be 3-50 characters' });
}
// Validate format
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (!emailRegex.test(email)) {
return res.status(400).json({ error: 'Invalid email format' });
}
// Validate ranges
const ageNum = parseInt(age);
if (isNaN(ageNum) || ageNum < 13 || ageNum > 120) {
return res.status(400).json({ error: 'Age must be between 13 and 120' });
}
// Sanitize for XSS (if needed for display)
const sanitizedUsername = escapeHtml(username);
const user = await db.createUser({
username: sanitizedUsername,
email,
age: ageNum
});
res.json(user);
});
// Option 2: Use validation library (Recommended)
const { body, validationResult } = require('express-validator');
app.post('/api/users',
// Validation middleware
body('username')
.isString()
.trim()
.isLength({ min: 3, max: 50 })
.escape(), // Prevents XSS
body('email')
.isEmail()
.normalizeEmail(),
body('age')
.isInt({ min: 13, max: 120 }),
async (req, res) => {
// Check validation results
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(400).json({ errors: errors.array() });
}
const { username, email, age } = req.body;
const user = await db.createUser({ username, email, age });
res.json(user);
}
);
Additional Security Measures:
1. Rate limiting (prevent abuse)
app.use(rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }));
2. Schema validation (Joi, Yup, Zod)
const schema = Joi.object({
username: Joi.string().min(3).max(50).required(),
email: Joi.string().email().required(),
age: Joi.number().integer().min(13).max(120).required()
});
3. Content-Type validation
Only accept application/json, reject others
4. Size limits
app.use(express.json({ limit: '10kb' }));
Best Practices:
- Whitelist valid input, don't blacklist bad input
- Validate on server side (client validation is not secure)
- Fail securely (reject invalid input)
- Provide clear error messages (but don't reveal system details)
- Log suspicious validation failures
Estimated effort: 1 hour
Priority: HIGH - Add before next deployment场景:用户的API端点接受用户输入
自动检测结果:技能识别到缺失验证:
⚠️ 安全问题检测到:缺失输入验证
位置:api/users.js,第45行
漏洞代码:
app.post('/api/users', async (req, res) => {
const { username, email, age } = req.body;
const user = await db.createUser({ username, email, age });
res.json(user);
});
问题:
1. 无输入类型验证
2. 无长度限制
3. 无格式验证(邮箱)
4. 无过滤处理(存在XSS风险)
风险:中到高
- 数据完整性问题
- 潜在XSS风险
- 意外输入导致数据库错误
- 业务逻辑被绕过
攻击场景:
1. 类型混淆:
POST { "age": "definitely not a number" }
可能导致数据库错误或逻辑漏洞
2. 超长输入:
POST { "username": "A".repeat(1000000) }
可能导致内存问题或拒绝服务
3. XSS注入:
POST { "username": "<script>alert('xss')</script>" }
如果用户名在HTML中显示,会执行JavaScript
4. 邮箱格式错误:
POST { "email": "not-an-email" }
破坏邮箱相关功能
安全修复方案:
// 选项1:手动验证
app.post('/api/users', async (req, res) => {
const { username, email, age } = req.body;
// 验证类型
if (typeof username !== 'string' || typeof email !== 'string') {
return res.status(400).json({ error: 'Invalid input types' });
}
// 验证长度
if (username.length < 3 || username.length > 50) {
return res.status(400).json({ error: 'Username must be 3-50 characters' });
}
// 验证格式
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (!emailRegex.test(email)) {
return res.status(400).json({ error: 'Invalid email format' });
}
// 验证范围
const ageNum = parseInt(age);
if (isNaN(ageNum) || ageNum < 13 || ageNum > 120) {
return res.status(400).json({ error: 'Age must be between 13 and 120' });
}
// 过滤处理以防止XSS(如果需要展示的话)
const sanitizedUsername = escapeHtml(username);
const user = await db.createUser({
username: sanitizedUsername,
email,
age: ageNum
});
res.json(user);
});
// 选项2:使用验证库(推荐)
const { body, validationResult } = require('express-validator');
app.post('/api/users',
// 验证中间件
body('username')
.isString()
.trim()
.isLength({ min: 3, max: 50 })
.escape(), // 防止XSS
body('email')
.isEmail()
.normalizeEmail(),
body('age')
.isInt({ min: 13, max: 120 }),
async (req, res) => {
// 检查验证结果
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(400).json({ errors: errors.array() });
}
const { username, email, age } = req.body;
const user = await db.createUser({ username, email, age });
res.json(user);
}
);
额外安全措施:
1. 速率限制(防止滥用)
app.use(rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }));
2. Schema验证(Joi、Yup、Zod)
const schema = Joi.object({
username: Joi.string().min(3).max(50).required(),
email: Joi.string().email().required(),
age: Joi.number().integer().min(13).max(120).required()
});
3. Content-Type验证
仅接受application/json,拒绝其他类型
4. 大小限制
app.use(express.json({ limit: '10kb' }));
最佳实践:
- 白名单合法输入,而非黑名单非法输入
- 在服务端验证(客户端验证不安全)
- 安全失败(拒绝无效输入)
- 提供清晰的错误信息(但不要泄露系统细节)
- 记录可疑的验证失败
修复预估耗时:1小时
优先级:高 - 下次部署前添加Error Handling
错误处理
- If language not supported: Provide generic security guidance
- If context insufficient: Ask for framework/usage details
- If no issues found: Confirm and suggest security best practices
- If false positive suspected: Provide rationale and allow override
- 如果语言不支持:提供通用安全指导
- 如果上下文不足:询问框架/使用细节
- 如果未发现问题:确认无漏洞并建议安全最佳实践
- 如果疑似误报:提供理由并允许覆盖
Risk Scoring
风险评分
Issues scored by CVSS-like criteria:
- Critical (9.0-10.0): SQL injection, RCE, auth bypass
- High (7.0-8.9): XSS, CSRF, sensitive data exposure
- Medium (4.0-6.9): Missing security headers, weak crypto
- Low (0.1-3.9): Information disclosure, minor config issues
基于类CVSS标准评分:
- Critical(9.0-10.0):SQL注入、远程代码执行、身份验证绕过
- High(7.0-8.9):XSS、CSRF、敏感数据暴露
- Medium(4.0-6.9):缺失安全头、弱加密
- Low(0.1-3.9):信息泄露、轻微配置问题
Integration with Workflow
工作流集成
- Proactive: Catches vulnerabilities during development
- Educational: Explains attack scenarios and impact
- Standards-Based: References OWASP, CWE, compliance requirements
- Actionable: Provides specific secure code examples
- Prioritized: Critical issues highlighted first
- 主动式:在开发阶段捕获漏洞
- 教育性:解释攻击场景与影响
- 基于标准:参考OWASP、CWE、合规要求
- 可执行:提供具体的安全代码示例
- 优先级排序:优先高亮严重问题
Compliance Mapping
合规映射
Maps findings to:
- OWASP Top 10 (2021)
- CWE (Common Weakness Enumeration)
- PCI-DSS requirements
- HIPAA security rules
- GDPR data protection requirements
检测结果可映射到:
- OWASP Top 10(2021)
- CWE(通用弱点枚举)
- PCI-DSS要求
- HIPAA安全规则
- GDPR数据保护要求
Related Skills
相关技能
- : General code quality
detect-code-smells - : Performance optimization
suggest-performance-fix
- :通用代码质量检查
detect-code-smells - :性能优化建议
suggest-performance-fix
Notes
注意事项
This skill embodies the senior developer mindset: "Security is not an afterthought." It catches common vulnerabilities early when they're cheap to fix, rather than in production where they're expensive disasters.
Security principles:
- Defense in depth (multiple layers)
- Least privilege (minimal permissions)
- Fail securely (deny by default)
- Don't trust user input (validate everything)
- Keep it simple (complex systems are insecure)
本技能体现了资深开发者的思维:"安全不是事后补救措施。" 它能在漏洞修复成本较低的开发早期发现常见问题,而非等到生产环境中造成昂贵的灾难。
安全原则:
- 纵深防御(多层防护)
- 最小权限(最小化权限)
- 安全失败(默认拒绝)
- 不信任用户输入(验证所有输入)
- 保持简单(复杂系统更不安全)