Создали сайт через ИИ: топ-10 шагов проверки безопасности перед запуском
Полный пошаговый чек-лист кибербезопасности для проектов, собранных в Cursor, Lovable, Bolt.new или v0. Как найти зашитые API-ключи, дыры в Supabase RLS, открытые .env и защитить сервис от взлома.
Появление инструментов вайб-кодинга совершило революцию: создать рабочий SaaS-стартап, каталог или маркетплейс в Cursor, Lovable, Bolt.new или v0.dev теперь можно буквально за выходные. Однако нейросети пишут код с единственной целью — чтобы он визуально работал прямо сейчас. Вопросы авторизации, изоляции секретных токенов и защиты баз данных языковые модели систематически игнорируют.
Если запустить проект в бой без предварительного аудита, уже в первые 48 часов автоматические боты извлекут ваши платные ключи OpenAI или Stripe из фронтенд-кода, либо выгрузят клиентскую базу через забытые политики базы данных. Мы подготовили топ-10 обязательных шагов проверки безопасности, которые должен выполнить каждый фаундер перед публичным релизом.
1. Проверка клиентского JS-бандла на зашитые API-ключи
Самая частая ошибка ИИ — генерация прямого вызова OpenAI, Stripe или Anthropic прямо из клиентского React/Vue компонента с префиксом NEXT_PUBLIC_ или VITE_. При сборке проект упаковывает эти ключи в публичный файл .js, откуда любой желающий может скопировать их за 5 секунд через DevTools.
# Поиск забытых секретных ключей в исходном коде перед билдом:
grep -rn "sk-proj-" ./src
grep -rn "sk_live_" ./src
grep -rn "NEXT_PUBLIC_OPENAI" ./src
2. Аудит политик Row Level Security (RLS) в Supabase и Firebase
Инструменты вроде Lovable и Bolt по умолчанию создают таблицы в базе данных Supabase. Если RLS не включен или настроена политика 'FOR ALL TO public USING (true)', любой пользователь может отправить REST-запрос к вашему Supabase эндпоинту и скачать всю таблицу пользователей или заказов.
-- Включение обязательного RLS для таблицы профилей:
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
-- Разрешить чтение только владельцу записи:
CREATE POLICY "Users can only read own profile"
ON profiles FOR SELECT
TO authenticated
USING (auth.uid() = id);
3. Блокировка доступа к .env, .git и локальным бэкапам
При деплое на VPS начинающие разработчики копируют папку проекта целиком вместе с файлом .env и директорией .git. Если веб-сервер настроен некорректно, любой сканер скачивает https://your-site.com/.env и получает все пароли от БД и SMTP.
# Запрет отдачи скрытых файлов и .git в Nginx
location ~ /\.(?!well-known) {
deny all;
access_log off;
log_not_found off;
return 404;
}
4. Закрытие публичных портов СУБД (5432, 27017, 6379)
Если вы развернули PostgreSQL, Redis или MongoDB на своем сервере, убедитесь, что порты баз данных привязаны строго к 127.0.0.1 (локальный хост) или внутренней Docker-сети, а не к внешнему IP 0.0.0.0.
5. Отключение Source Maps в production-сборке
Source maps (.js.map) позволяют разработчику видеть оригинальный TypeScript код в браузере. Однако в продакшене они открывают злоумышленникам полную архитектуру вашего бэкенда, внутренние типы данных и скрытые эндпоинты. Отключайте их в vite.config.ts или next.config.js.
// next.config.js
module.exports = {
productionBrowserSourceMaps: false,
};
6. Ограничение частоты запросов (Rate Limiting) на эндпоинтах авторизации
Эндпоинты генерации текста, отправки SMS-кодов или сброса пароля без лимита запросов позволяют злоумышленникам быстро исчерпать ваш баланс API или устроить брутфорс авторизации.
7. Проверка зависимостей и supply chain атак
ИИ нередко галлюцинирует несуществующими npm-пакетами. Хакеры регистрируют эти имена в npm-реестре и внедряют туда вредоносный код. Обязательно выполните команду аудита пакетов перед билдом.
npm audit --audit-level=high
8. Внедрение строгих заголовков безопасности (CSP, HSTS, X-Frame-Options)
Заголовки безопасности защищают ваше приложение от кликджекинга, атак XSS и перехвата сессий. Настройте HSTS с preload и Content-Security-Policy для блокировки сторонних инъекций скриптов.
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
9. Настройка безопасных атрибутов Cookie
Сессионные токены пользователей никогда не должны читаться через JavaScript. Убедитесь, что все авторизационные куки имеют флаги HttpOnly, Secure и SameSite=Lax (или Strict), что исключает кражу сессии через XSS.
10. Запуск глубокого 24-часового сканирования периметра
Финальный и самый надежный шаг — запустить неразрушающий аудит через автоматизированный сканер Site Check. Сервис проверит доступность портов, наличие открытых бэкапов, правильность SSL, отсутствие утечек ключей и пришлет подробный отчет с готовыми промптами для исправления.
Чек-лист безопасности для разработчика
- ✓ Проверить код фронтенда на отсутствие приватных ключей OpenAI, Stripe, Resend
- ✓ Убедиться, что для всех таблиц базы данных включен Row Level Security (RLS)
- ✓ Проверить веб-сервер на недоступность файлов .env, .git и .DS_Store
- ✓ Убедиться, что порты СУБД (5432, 6379, 27017) закрыты для внешнего интернета
- ✓ Отключить генерацию production source maps в конфигурации сборщика
- ✓ Настроить ограничение частоты запросов (Rate Limiting) на API эндпоинтах
- ✓ Запустить npm audit и проверить зависимости на галлюцинации пакетов
- ✓ Прописать защитные HTTP-заголовки (HSTS, CSP, X-Frame-Options, nosniff)
- ✓ Проверить сессионные куки на наличие флагов HttpOnly и Secure
- ✓ Запустить комплексный 24-часовой аудит проекта в сканере Site Check
Резюме и ключевые выводы аудитора безопасности
При запуске веб-сервисов и приложений на базе современных фреймворков (Next.js, Astro, React, Supabase) безопасность периметра не должна быть второстепенным этапом. Более 85% утечек конфиденциальных данных и взломов баз данных происходят не из-за изощрённых уязвимостей нулевого дня (0-day), а по причине тривиальных ошибок конфигурации: забытых тестовых эндпоинтов, открытых файлов окружения, некорректных правил CORS и отсутствия строгих политик разграничения доступа (RLS).
Регулярный превентивный аудит внешнего контура с помощью Site Check позволяет обнаружить опасные сигнатуры за считанные секунды и закрыть векторы атак до того, как они попадут в поле зрения автоматизированных ботнетов.