Чеклист по безопасности для вайбкодеров: 11 шагов перед релизом приложения

С развитием «вайбкодинга» (скоростной разработки с использованием ИИ), путь от идеи до продакшена сократился до считанных часов. Однако у этой медали есть обратная сторона: приложения выходят к реальным пользователям без базовой защиты. Результат — счета от Supabase на $200 за сутки, базы данных, слитые через DevTools, и претензии регуляторов по GDPR.

Разработчик с 20-летним опытом Prajwal Tomar опубликовал манифест-чеклист, который поможет закрыть критические дыры в безопасности перед тем, как вы нажмёте кнопку «Deploy».

1. Юридический щит: GDPR и CCPA

Защищайте не только код, но и себя. Как только вы начинаете собирать данные пользователей (даже просто email), вступают в силу юридические требования: GDPR (Европа) и CCPA (США).

• Что сделать: Подготовьте политику конфиденциальности (Privacy Policy).
• Важно: Вы должны точно знать, в каком дата-центре хранятся данные и как пользователь может их удалить. Использование ИИ для генерации текста политики — хорошая база, но проверьте её на соответствие реальности.

2. Row Level Security (RLS) в Supabase

Без RLS любой человек может открыть консоль разработчика (DevTools) и прочитать содержимое всей вашей базы знаний.

• Что сделать: В Supabase перейдите в Auth → Policies.
• Действие: Настройте политики доступа. Если их нет — база открыта для интернета. Настройка занимает 5 минут, но экономит годы репутации.

3. Стресс-тест аутентификации

ИИ отлично пишет «счастливый путь» пользователя (Happy Path), но часто игнорирует ошибки.

• Эксперимент:
  • Введите неправильный пароль 5 раз подряд.
  • Сбросьте пароль для несуществующей почты.
  • Попробуйте зарегистрироваться с уже существующим email.
  • Откройте ссылку подтверждения дважды. Именно так находят 90% багов систем входа.

4. Инспекция с помощью ИИ

Используйте силу того же ИИ для аудита.

• Запрос для ИИ: «Проверь моё приложение как специалист по безопасности и убедись, что у меня сильные заголовки безопасности (Security Headers) и надёжный базовый уровень».

5. Соответствие стандартам OWASP

OWASP Top 10 — это библия уязвимостей (SQL-инъекции, XSS и др.).

• Запрос для ИИ: «Проверь моё приложение на соответствие стандартам OWASP и подсвети потенциальные уязвимости». Это поможет выявить ошибки, которые «глаз замылился» не замечать.

6. Двойная валидация

Валидация на фронтенде — это только удобство для пользователя, а не защита.

• Правило: Злоумышленник может отключить JavaScript и отправить запрос к API напрямую. Все проверки должны дублироваться на сервере.

7. Поиск утечек чувствительных данных

Код от ИИ склонен к «болтливости». Проверьте три места: 1. Попадают ли значения из .env во фронтенд? 2. Возвращает ли API лишние поля из БД (например, хэши паролей)? 3. Не пишутся ли секретные ключи в логи сервера?

• Запрос для ИИ: «Проверь моё приложение на утечки credentials или чувствительных данных во фронтенде или API-роутах».

8. Изоляция API-ключей

Это золотое правило. API-ключи не должны находиться во фронтенд-коде.

• Решение: Если ключ виден в браузере — он скомпрометирован. Все запросы к сторонним сервисам (OpenAI, Stripe и т.д.) проводите через свой бэкенд или прокси.

9. Настройка Rate Limiting (лимиты запросов)

Без ограничений один бот может накрутить вам счёт с 20до20 до20до200 за день, просто заспамив эндпоинт, вызывающий платную модель.

• Что сделать: Ограничьте количество запросов в минуту для каждого IP (особенно для платных функций). Добавьте уведомления о превышении лимитов трат в облачных панелях.

10. Защита от ботов: CAPTCHA и CORS

Массовые регистрации ботов забивают базу и портят аналитику.

• Решение: Установите бесплатный Cloudflare Turnstile на публичные формы.
• CORS: Настройте ограничения на сервере так, чтобы запросы принимались только с вашего домена. Это работа на 10 минут.

11. Маскировка ошибок сервера

Никогда не показывайте пользователю внутренние системные ошибки.

• Плохо: «Internal Server Error: SELECT * FROM users WHERE id=... failed». Это подсказка для хакера о структуре вашей БД.
• Хорошо: «Пользователь не найден» или «Что-то пошло не так». Подробности пишите только в логи.