Вайб-кодинг и ИИ 2026-10-12 9 мин ЧТЕНИЯ

Создали сайт через ИИ: топ-10 шагов проверки безопасности перед запуском

Полный пошаговый чек-лист кибербезопасности для проектов, собранных в Cursor, Lovable, Bolt.new или v0. Как найти зашитые API-ключи, дыры в Supabase RLS, открытые .env и защитить сервис от взлома.

S Автор: Команда Site Check Security

Появление инструментов вайб-кодинга совершило революцию: создать рабочий 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
                  # Поиск забытых секретных ключей в исходном коде перед билдом:
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 в Supabase PostgreSQL
                  -- Включение обязательного 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.

Обратите внимание: Сканеры Shodan и Censys индексируют открытые порты баз данных за считанные минуты. Если у Redis или PostgreSQL слабый пароль, данные удалят или зашифруют вымогатели.

5. Отключение Source Maps в production-сборке

Source maps (.js.map) позволяют разработчику видеть оригинальный TypeScript код в браузере. Однако в продакшене они открывают злоумышленникам полную архитектуру вашего бэкенда, внутренние типы данных и скрытые эндпоинты. Отключайте их в vite.config.ts или next.config.js.

Отключение генерации source maps в Next.js
                  // next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
};
                

6. Ограничение частоты запросов (Rate Limiting) на эндпоинтах авторизации

Эндпоинты генерации текста, отправки SMS-кодов или сброса пароля без лимита запросов позволяют злоумышленникам быстро исчерпать ваш баланс API или устроить брутфорс авторизации.

Обратите внимание: Используйте встроенный Nginx limit_req_zone или библиотеку Upstash Ratelimit для защиты серверных функций.

7. Проверка зависимостей и supply chain атак

ИИ нередко галлюцинирует несуществующими npm-пакетами. Хакеры регистрируют эти имена в 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 позволяет обнаружить опасные сигнатуры за считанные секунды и закрыть векторы атак до того, как они попадут в поле зрения автоматизированных ботнетов.