Security Review
Улучшите Claude Code с помощью профессиональных аудитов безопасности. Защитите свои приложения, следуя лучшим практикам для аутентификации, секретов, валидации ввода и предотвращения уязвимостей.
Навык Security Review предоставляет комплексную систему для проверки соответствия кодовых баз современным стандартам безопасности и лучшим практикам. Он помогает разработчикам пройти ключевые контрольные точки: управление секретами, валидацию входных данных через Zod, предотвращение SQL-инъекций и безопасные потоки аутентификации. Благодаря стандартизированным шаблонам кода с вердиктом «Пройдено/Не пройдено» и автоматизированным тестам этот навык помогает снизить риск таких распространённых уязвимостей, как XSS, CSRF и утечка чувствительных данных, что делает его незаменимым инструментом для создания надёжных, защищённых приложений с Claude Code.
Ключевые возможности
Варианты использования
| name | security-review | ||
|---|---|---|---|
| description | Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides comprehensive security checklist and patterns. | ||
| metadata |
|
This skill ensures all code follows security best practices and identifies potential vulnerabilities.
- Implementing authentication or authorization
- Handling user input or file uploads
- Creating new API endpoints
- Working with secrets or credentials
- Implementing payment features
- Storing or transmitting sensitive data
- Integrating third-party APIs
const apiKey = "sk-proj-xxxxx" // Hardcoded secret
const dbPassword = "password123" // In source codeconst apiKey = process.env.OPENAI_API_KEY
const dbUrl = process.env.DATABASE_URL
// Verify secrets exist
if (!apiKey) {
throw new Error('OPENAI_API_KEY not configured')
}- No hardcoded API keys, tokens, or passwords
- All secrets in environment variables
-
.env.localin .gitignore - No secrets in git history
- Production secrets in hosting platform (Vercel, Railway)
import { z } from 'zod'
// Define validation schema
const CreateUserSchema = z.object({
email: z.string().email(),
name: z.string().min(1).max(100),
age: z.number().int().min(0).max(150)
})
// Validate before processing
export async function createUser(input: unknown) {
try {
const validated = CreateUserSchema.parse(input)
return await db.users.create(validated)
} catch (error) {
if (error instanceof z.ZodError) {
return { success: false, errors: error.errors }
}
throw error
}
}function validateFileUpload(file: File) {
// Size check (5MB max)
const maxSize = 5 * 1024 * 1024
if (file.size > maxSize) {
throw new Error('File too large (max 5MB)')
}
// Type check
const allowedTypes = ['image/jpeg', 'image/png', 'image/gif']
if (!allowedTypes.includes(file.type)) {
throw new Error('Invalid file type')
}
// Extension check
const allowedExtensions = ['.jpg', '.jpeg', '.png', '.gif']
const extension = file.name.toLowerCase().match(/\.[^.]+$/)?.[0]
if (!extension || !allowedExtensions.includes(extension)) {
throw new Error('Invalid file extension')
}
return true
}- All user inputs validated with schemas
- File uploads restricted (size, type, extension)
- No direct use of user input in queries
- Whitelist validation (not blacklist)
- Error messages don't leak sensitive info
// DANGEROUS - SQL Injection vulnerability
const query = `SELECT * FROM users WHERE email = '${userEmail}'`
await db.query(query)// Safe - parameterized query
const { data } = await supabase
.from('users')
.select('*')
.eq('email', userEmail)
// Or with raw SQL
await db.query(
'SELECT * FROM users WHERE email = $1',
[userEmail]
)- All database queries use parameterized queries
- No string concatenation in SQL
- ORM/query builder used correctly
- Supabase queries properly sanitized
// FAIL: WRONG: localStorage (vulnerable to XSS)
localStorage.setItem('token', token)
// PASS: CORRECT: httpOnly cookies
res.setHeader('Set-Cookie',
`token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`)export async function deleteUser(userId: string, requesterId: string) {
// ALWAYS verify authorization first
const requester = await db.users.findUnique({
where: { id: requesterId }
})
if (requester.role !== 'admin') {
return NextResponse.json(
{ error: 'Unauthorized' },
{ status: 403 }
)
}
// Proceed with deletion
await db.users.delete({ where: { id: userId } })
}-- Enable RLS on all tables
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
-- Users can only view their own data
CREATE POLICY "Users view own data"
ON users FOR SELECT
USING (auth.uid() = id);
-- Users can only update their own data
CREATE POLICY "Users update own data"
ON users FOR UPDATE
USING (auth.uid() = id);- Tokens stored in httpOnly cookies (not localStorage)
- Authorization checks before sensitive operations
- Row Level Security enabled in Supabase
- Role-based access control implemented
- Session management secure
import DOMPurify from 'isomorphic-dompurify'
// ALWAYS sanitize user-provided HTML
function renderUserContent(html: string) {
const clean = DOMPurify.sanitize(html, {
ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'],
ALLOWED_ATTR: []
})
return <div dangerouslySetInnerHTML={{ __html: clean }} />
}// next.config.js
const securityHeaders = [
{
key: 'Content-Security-Policy',
value: `
default-src 'self';
script-src 'self' 'unsafe-eval' 'unsafe-inline';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
font-src 'self';
connect-src 'self' https://api.example.com;
`.replace(/\s{2,}/g, ' ').trim()
}
]- User-provided HTML sanitized
- CSP headers configured
- No unvalidated dynamic content rendering
- React's built-in XSS protection used
import { csrf } from '@/lib/csrf'
export async function POST(request: Request) {
const token = request.headers.get('X-CSRF-Token')
if (!csrf.verify(token)) {
return NextResponse.json(
{ error: 'Invalid CSRF token' },
{ status: 403 }
)
}
// Process request
}res.setHeader('Set-Cookie',
`session=${sessionId}; HttpOnly; Secure; SameSite=Strict`)- CSRF tokens on state-changing operations
- SameSite=Strict on all cookies
- Double-submit cookie pattern implemented
import rateLimit from 'express-rate-limit'
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // 100 requests per window
message: 'Too many requests'
})
// Apply to routes
app.use('/api/', limiter)// Aggressive rate limiting for searches
const searchLimiter = rateLimit({
windowMs: 60 * 1000, // 1 minute
max: 10, // 10 requests per minute
message: 'Too many search requests'
})
app.use('/api/search', searchLimiter)- Rate limiting on all API endpoints
- Stricter limits on expensive operations
- IP-based rate limiting
- User-based rate limiting (authenticated)
// FAIL: WRONG: Logging sensitive data
console.log('User login:', { email, password })
console.log('Payment:', { cardNumber, cvv })
// PASS: CORRECT: Redact sensitive data
console.log('User login:', { email, userId })
console.log('Payment:', { last4: card.last4, userId })// FAIL: WRONG: Exposing internal details
catch (error) {
return NextResponse.json(
{ error: error.message, stack: error.stack },
{ status: 500 }
)
}
// PASS: CORRECT: Generic error messages
catch (error) {
console.error('Internal error:', error)
return NextResponse.json(
{ error: 'An error occurred. Please try again.' },
{ status: 500 }
)
}- No passwords, tokens, or secrets in logs
- Error messages generic for users
- Detailed errors only in server logs
- No stack traces exposed to users
import { verify } from '@solana/web3.js'
async function verifyWalletOwnership(
publicKey: string,
signature: string,
message: string
) {
try {
const isValid = verify(
Buffer.from(message),
Buffer.from(signature, 'base64'),
Buffer.from(publicKey, 'base64')
)
return isValid
} catch (error) {
return false
}
}async function verifyTransaction(transaction: Transaction) {
// Verify recipient
if (transaction.to !== expectedRecipient) {
throw new Error('Invalid recipient')
}
// Verify amount
if (transaction.amount > maxAmount) {
throw new Error('Amount exceeds limit')
}
// Verify user has sufficient balance
const balance = await getBalance(transaction.from)
if (balance < transaction.amount) {
throw new Error('Insufficient balance')
}
return true
}- Wallet signatures verified
- Transaction details validated
- Balance checks before transactions
- No blind transaction signing
# Check for vulnerabilities
npm audit
# Fix automatically fixable issues
npm audit fix
# Update dependencies
npm update
# Check for outdated packages
npm outdated# ALWAYS commit lock files
git add package-lock.json
# Use in CI/CD for reproducible builds
npm ci # Instead of npm install- Dependencies up to date
- No known vulnerabilities (npm audit clean)
- Lock files committed
- Dependabot enabled on GitHub
- Regular security updates
// Test authentication
test('requires authentication', async () => {
const response = await fetch('/api/protected')
expect(response.status).toBe(401)
})
// Test authorization
test('requires admin role', async () => {
const response = await fetch('/api/admin', {
headers: { Authorization: `Bearer ${userToken}` }
})
expect(response.status).toBe(403)
})
// Test input validation
test('rejects invalid input', async () => {
const response = await fetch('/api/users', {
method: 'POST',
body: JSON.stringify({ email: 'not-an-email' })
})
expect(response.status).toBe(400)
})
// Test rate limiting
test('enforces rate limits', async () => {
const requests = Array(101).fill(null).map(() =>
fetch('/api/endpoint')
)
const responses = await Promise.all(requests)
const tooManyRequests = responses.filter(r => r.status === 429)
expect(tooManyRequests.length).toBeGreaterThan(0)
})Before ANY production deployment:
- Secrets: No hardcoded secrets, all in env vars
- Input Validation: All user inputs validated
- SQL Injection: All queries parameterized
- XSS: User content sanitized
- CSRF: Protection enabled
- Authentication: Proper token handling
- Authorization: Role checks in place
- Rate Limiting: Enabled on all endpoints
- HTTPS: Enforced in production
- Security Headers: CSP, X-Frame-Options configured
- Error Handling: No sensitive data in errors
- Logging: No sensitive data logged
- Dependencies: Up to date, no vulnerabilities
- Row Level Security: Enabled in Supabase
- CORS: Properly configured
- File Uploads: Validated (size, type)
- Wallet Signatures: Verified (if blockchain)
Remember: Security is not optional. One vulnerability can compromise the entire platform. When in doubt, err on the side of caution.
Что это 🛡️
Security Review — это не автоматический сканер, а регламентированный набор чек-листов и паттернов безопасной разработки. Скилл предназначен для тех моментов, когда код касается sensitive-операций: аутентификация, работа с пользовательским вводом, секреты, платежи, API-эндпоинты и интеграции. Он напоминает о критических проверках на каждом этапе — от валидации входа до защиты блокчейн-кошельков и деплоймент-релизов.
Как работает 🔄
📌 Управление секретами (Secrets Management)
Никогда не хардкодьте ключи, токены или пароли напрямую в исходниках. Правильный подход — все секреты выносятся в переменные окружения (process.env.*), проверяется их наличие, а .env.local обязательно добавляется в .gitignore. В продакшене секреты хранятся в платформе хостинга (Vercel, Railway).
# PASS — безопасно
const apiKey = process.env.OPENAI_API_KEY
if (!apiKey) throw new Error('OPENAI_API_KEY not configured')
📌 Валидация ввода (Input Validation)
Любой ввод от пользователя (тело запроса, параметры URL, заголовки) должен быть провалидирован до того, как попадёт в бизнес-логику. Используй схемы (Zod, Yup) — это даёт чёткие типы и понятные ошибки. Для файлов проверяй размер (например, макс. 5 MB), тип MIME и расширение. Ошибки валидации не должны раскрывать внутреннюю структуру.
const CreateUserSchema = z.object({
email: z.string().email(),
name: z.string().min(1).max(100),
age: z.number().int().min(0).max(150)
})
📌 Защита от SQL-инъекций (SQL Injection Prevention)
Категорически запрещено конкатенировать пользовательский ввод в SQL. Всегда используй параметризованные запросы (плейсхолдеры $1, $2 или ORM-методы вроде .eq('email', userEmail)). Supabase-запросы уже санитизированы при правильном использовании SDK.
📌 Аутентификация и авторизация (Authentication & Authorization)
JWT-токены НЕ хранятся в localStorage — это уязвимо к XSS. Используй httpOnly, Secure, SameSite Strict куки. Перед каждым sensitive-действием проверяй роль или права запрашивающего (например, requester.role !== 'admin' → 403). В Supabase обязательно включай Row Level Security (RLS) и создавай политики на каждую таблицу.
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users view own data" ON users FOR SELECT USING (auth.uid() = id);
📌 Защита от XSS и CSRF
Любой HTML от пользователя (комментарии, профили) санитизируется через DOMPurify с whitelist-списком разрешённых тегов. Content Security Policy (CSP) настраивается в заголовках ответа — это дополнительный слой защиты даже при ошибке в коде.
Для CSRF используй токены в заголовке (X-CSRF-Token) и SameSite=Strict на всех куках. Это предотвращает атаки с подделкой запросов.
📌 Лимитирование запросов (Rate Limiting)
Защита от brute-force, DDoS — на каждый API-эндпоинт устанавливается лимит (например, 100 запросов за 15 минут). Для тяжёлых операций (поиск, экспорт) лимиты ужесточаются. Применяй как IP-базированные, так и user-базированные (для аутентифицированных) ограничения.
📌 Обработка sensitive-данных (Sensitive Data Exposure)
В логи никогда не пишутся пароли, токены, номера карт, CVV-коды. Вместо этого логируй только минимум: userId, last4 номера карты, действие. Ошибки пользователям отдаются общими фразами («Произошла ошибка»), а подробности (стектрейс, сообщение) — только в серверные логи.
📌 Специфика блокчейна (Solana)
Если проект работает с Solana, жёстко проверяются подпись кошелька (verify), корректность получателя и суммы транзакции, а также баланс перед списанием. Никакого «слепого» подписания.
📌 Безопасность зависимостей (Dependency Security)
Регулярно запускай npm audit, фикс уязвимостей через npm audit fix, коммить package-lock.json. На GitHub включай Dependabot для автоматических PR с обновлениями.
📌 Security-тесты и преддеплойный чеклист
Покрывай unit-тестами ключевые сценарии: неавторизованный доступ возвращает 401, недостаточные права — 403, невалидный ввод — 400, rate limiting — 429. Перед каждым продакшен-релизом пройди по чеклисту из ~20 пунктов: секреты, валидация, SQL-инъекции, XSS, CSRF, аутентификация, авторизация, rate limiting, HTTPS, security-заголовки, CORS, логи, зависимости, RLS, файловые аплоады, подписи кошельков и т.д.
Когда использовать 🚦
- На этапе разработки — когда пишешь новый эндпоинт, форму ввода, интеграцию с платежами, регистрацию/логин, работу с файлами.
- Во время code review — прогнать чеклист перед мержем PR.
- Перед деплоем — финальная верификация, что ни один пункт безопасности не пропущен.
- При интеграции внешних сервисов — проверь, что API-ключи не засвечены, вызовы защищены, ответы не содержат sensitive-данных.
- После аудита безопасности — как референс для исправления найденных уязвимостей.
Важно знать ⚠️
- Security Review — это не замена автоматическим сканерам, а руководство для разработчика, чтобы не забыть очевидные, но критичные вещи.
- Всегда используй whitelist (разрешаем только то, что нужно), а не blacklist (пытаемся запретить плохое) — это надёжнее.
- Никогда не доверяй пользовательскому вводу — даже если он приходит с фронтенда, который ты сам написал.
- Одна уязвимость может скомпрометировать всю платформу. Если сомневаешься — перепроверь или спроси коллегу.
- Чеклист составлен с учётом OWASP Top 10, лучших практик Next.js, Supabase и Solana (если применимо).
Итог: этот скилл — твой напарник, который каждый раз напоминает: «А ты проверил?», прежде чем код уйдёт в продакшен.
Как навык Security Review помогает предотвратить SQL-инъекции?
Навык требует использования параметризованных запросов и лучших практик ORM, предоставляя четкие примеры и шаги проверки, чтобы запретить опасную конкатенацию строк в вызовах базы данных.
Поддерживает ли он безопасность для блокчейна?
Да, он предоставляет специализированные шаги проверки для подтверждения владения кошельком Solana и обеспечения безопасного взаимодействия в средах Web3.
Как использовать чек-лист перед развертыванием?
Навык предоставляет чек-лист из 17 пунктов, охватывающий все: от принудительного использования HTTPS и заголовков CSP до Row Level Security (RLS) и аудита зависимостей.
Может ли этот навык помочь с утечкой конфиденциальных данных в логах?
Да, он включает конкретные рекомендации и шаги проверки для выявления и маскирования конфиденциальной информации, такой как пароли, номера кредитных карт и API-ключи, в консольных логах и сообщениях об ошибках.
Синхронизируйте навыки в Claude Cowork, Claude Code, Codex и другие.
Установка одной командой.
npx skillfish add affaan-m/everything-claude-code security-reviewИсточник: https://mcpmarket.com/tools/skills/security-review-1777849917738
Комментарии
Комментариев пока нет. Будьте первым.