🔐 Что это
Security Review Expert — это структурированный чек-лист и набор паттернов для аудита безопасности кода. Он предназначен для разработчиков, которые хотят избежать типовых уязвимостей при работе с аутентификацией, пользовательским вводом, секретами, API, платежами или чувствительными данными. Скилл не просто перечисляет правила, а даёт конкретные примеры неправильного (FAIL) и правильного (PASS) кода, а также шаги для верификации.
⚙️ Как работает
Скилл охватывает 10 ключевых областей безопасности. Для каждой из них приведены антипаттерны, корректные реализации и чек-пойнты для проверки.
1. Управление секретами 🗝️
Запрещено хардкодить ключи и пароли в исходном коде. Все секреты должны храниться в переменных окружения (process.env.*) или на платформе размещения (Vercel, Railway). Файл .env.local обязательно добавляется в .gitignore. Перед деплоем проверяется, что секреты не засветились в Git-истории.
# Пример: проверка наличия ключа
if (!process.env.OPENAI_API_KEY) { throw new Error('OPENAI_API_KEY not configured') }
2. Валидация пользовательского ввода 📝
Все входные данные должны проходить строгую проверку по схеме — рекомендуется использовать zod. Для файлов проверяется размер (до 5MB), MIME-тип и расширение. Валидация строится на белом списке разрешённых значений, а не на чёрном. Сообщения об ошибках не должны раскрывать внутренние детали системы.
3. Защита от SQL-инъекций 🛡️
Категорически запрещена конкатенация строк в SQL-запросах. Все запросы должны быть параметризованными (через ORM/query builder или позиционные параметры типа $1).
-- FAIL (опасно!)
const query = `SELECT * FROM users WHERE email = '${userEmail}'`
-- PASS (безопасно)
const { data } = await supabase.from('users').select('*').eq('email', userEmail)
4. Аутентификация и авторизация 🚪
JWT-токены должны храниться в httpOnly cookie с флагами Secure и SameSite=Strict, а не в localStorage (уязвим к XSS). Перед каждой критической операцией (удаление, изменение ролей) обязательно проверяется, что пользователь авторизован. Для Supabase рекомендуется включить Row Level Security (RLS) на всех таблицах.
5. Защита от XSS 🔥
Любой HTML, полученный от пользователя, должен быть очищен с помощью библиотеки вроде DOMPurify — разрешены только безопасные теги (b, i, em, strong, p) и никаких атрибутов. На уровне приложения настраивается Content Security Policy (CSP) — заголовок Content-Security-Policy в next.config.js.
6. CSRF-защита 🔄
Для операций, изменяющих состояние, обязательна проверка CSRF-токена (в заголовке X-CSRF-Token). Все куки должны иметь SameSite=Strict. Рекомендуется использовать паттерн double-submit cookie.
7. Rate Limiting ⏱️
Все API-эндпоинты должны быть защищены от чрезмерных запросов. Для дорогих операций (поиск, генерация) устанавливаются более жёсткие лимиты. Ограничение может быть как по IP, так и по аутентифицированному пользователю.
// Пример с express-rate-limit
const limiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100 })
app.use('/api/', limiter)
8. Защита от утечки чувствительных данных 🔍
В логи нельзя записывать пароли, токены или полные номера карт — только маскированные данные (последние 4 цифры). Пользователям показываются общие сообщения об ошибке (Произошла ошибка, попробуйте позже), а подробности (стектрейс) остаются только на сервере.
9. Blockchain-безопасность (Solana) ⛓️
Если приложение работает с блокчейном, требуется проверять подписи кошельков (verify из @solana/web3.js), а перед транзакциями — баланс пользователя и допустимую сумму. Запрещено подписывать «слепые» транзакции.
10. Безопасность зависимостей 📦
Регулярно запускайте npm audit и npm audit fix. Lock-файлы (package-lock.json) должны быть в репозитории — для сборок используйте npm ci вместо npm install. Рекомендуется включить Dependabot в GitHub для автоматических обновлений.
🧪 Когда использовать
Скилл активируется на этапе code review или перед деплоем в production. Особенно важен, если:
- Вы добавляете аутентификацию или авторизацию.
- Обрабатываете пользовательский ввод (формы, файлы).
- Создаёте новые API-эндпоинты.
- Работаете с секретами или платёжными данными.
- Интегрируете сторонние API.
- Используете Supabase, Solana или другие внешние сервисы.
Во всех этих случаях скилл помогает не пропустить распространённые уязвимости.
💡 Важно знать
- Не пропускайте шаги верификации — каждый пункт чек-листа сопровождается конкретными действиями для проверки.
- Автоматизируйте тесты — в скилле есть готовые примеры тестов для аутентификации, авторизации, валидации и rate limiting.
- Безопасность не опциональна — одна дыра может скомпрометировать всю платформу. Лучше перепроверить, чем потом исправлять инцидент.
Регулярное применение этого скилла на code review поможет сделать код надежным и защищённым от OWASP Top 10 и других типовых угроз.
Комментарии
Комментариев пока нет. Будьте первым.