5 ошибок безопасности, которые допускает каждый Vibe-разработчик (и как их исправить)

AI-генерируемый код работает. Он запускается. Он выглядит правильно. Но он также поставляется с одними и теми же пятью уязвимостями безопасности почти в каждом проекте. Это не теоретические риски — это конкретные дыры, которые появляются почти в каждой кодовой базе, созданной Claude, Cursor, Replit или Copilot, если вы явно не запросите безопасность.

Я провел аудит десятков проектов, написанных на вибрациях, за прошлый год, и одни и те же пять ошибок появляются как минимум в 80% из них. Каждую можно исправить менее чем за 30 минут. Вот на что обратить внимание и как именно это исправить.

Ошибка 1: API-ключи жестко закодированы в коде фронтенда

Как это происходит: Вы говорите Claude "подключиться к Supabase" или "добавить платежи Stripe", а он генерирует код с API-ключом, вставленным прямо в компонент React. Код работает идеально — и ваш секретный ключ видит каждый, кто откроет DevTools браузера и проверит вкладку Network или исходный код JavaScript.

Почему это опасно: Ваш сервисный ключ Supabase обходит всю безопасность базы данных. Ваш секретный ключ Stripe позволяет кому-то списывать деньги со счетов или делать возвраты. Ваш ключ OpenAI позволяет кому-то потратить тысячи рублей на вызовы API на вашем счете. Боты активно сканируют публичные репозитории GitHub и развернутые сайты на предмет раскрытых ключей.

Исправление: Переместите каждый секрет в переменные окружения. В Next.js только переменные, начинающиеся с NEXT_PUBLIC_, достигают браузера. Любой ключ, который дает доступ на запись, административный доступ или финансовый доступ, должен быть только на стороне сервера.

После перемещения ключей в .env.local поищите старые значения ключей во всей кодовой базе, чтобы убедиться, что они удалены. Затем проверьте историю Git — если ключ когда-либо был закоммичен, он все еще находится в истории вашего репозитория, даже если вы его удалили. Переустановите (ротируйте) любой ключ, который когда-либо был раскрыт, даже кратко.

Время на исправление: 15–30 минут.

Ошибка 2: таблицы Supabase без безопасности на уровне строк

Как это происходит: AI генерирует запросы создания таблиц Supabase и операции CRUD, но не включает Row-Level Security (RLS). По умолчанию таблицы Supabase с отключенным RLS полностью доступны для всех, у кого есть URL вашего проекта и анонимный ключ — оба из них являются публичными (и должны быть).

Почему это опасно: Без RLS Пользователь A может запрашивать данные Пользователя B. Простой вызов fetch из консоли браузера может получить каждую строку из каждой таблицы. Ваша вся база данных по сути является публичной.

Как это обнаружить: Перейдите в панель управления Supabase → Table Editor. Если какая-либо таблица показывает "RLS Disabled", у вас есть эта проблема. Также проверьте, использует ли ваш код на стороне клиента ключ service_role вместо ключа anon — это еще хуже.

Исправление: Включите RLS на каждой таблице. Затем создайте политики, которые соответствуют паттернам доступа вашего приложения. Наиболее распространенная политика: пользователи могут только SELECT, INSERT, UPDATE и DELETE строки, где auth.uid() = user_id. Протестируйте, войдя как один пользователь и попытавшись получить доступ к данным другого пользователя через REST API Supabase.

Время на исправление: 30–60 минут в зависимости от количества таблиц.

Ошибка 3: отсутствие валидации входных данных в формах или маршрутах API

Как это происходит: AI генерирует формы, которые принимают любые входные данные и маршруты API, которые доверяют любым поступающим данным. Форма имеет атрибут "required" в HTML, но нет валидации на стороне сервера. Кто-то обходит форму целиком, отправляя прямой запрос API с любым полезным грузом, который они хотят.

Почему это опасно: Без валидации на стороне сервера злоумышленники могут внедрять скрипты в вашу базу данных (stored XSS), отправлять слишком большие полезные грузы, которые ломают ваш сервер, или отправлять данные, которые нарушают логику вашего приложения (например, отрицательная цена или поле email, содержащее SQL).

Как это обнаружить: Откройте любой маршрут API или серверное действие в вашей кодовой базе. Если оно использует req.body или данные формы без проверки формы, типа и длины каждого поля, у вас есть эта проблема.

Исправление: Добавьте валидацию на стороне сервера к каждой конечной точке, используя библиотеку валидации схемы. Zod — это стандарт для проектов TypeScript:

import { z } from 'zod';

const taskSchema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']),
});

// In your API route:
const parsed = taskSchema.safeParse(req.body);
if (!parsed.success) {
  return Response.json({ error: parsed.error }, { status: 400 });
}

Для любого поля, которое отображается как HTML (комментарии, описания, био), также очищайте вывод с помощью DOMPurify перед его отображением.

Время на исправление: 30–60 минут.

Ошибка 4: отсутствие ограничения частоты запросов к конечным точкам API

Как это происходит: AI никогда не добавляет ограничение частоты запросов, если вы об этом не просите. Каждая конечная точка API, которую предоставляет ваше приложение, может быть поражена тысячи раз в секунду кем-либо со скриптом.

Почему это опасно: Без ограничения частоты запросов кто-то может подбирать пароль вашей конечной точки входа, скрейпить вашу базу данных, многократно попадая на конечные точки списка, перегружать ваш сервер (отказ в обслуживании) или сжигать вашу квоту API, если ваши конечные точки вызывают внешние услуги, такие как OpenAI или Stripe.

Как это обнаружить: Если ни один из ваших маршрутов API не проверяет, сколько запросов сделала одна IP-адрес или пользователь недавно, у вас нет ограничения частоты запросов.

Исправление: Самый простой подход для приложений, размещенных на Vercel, — это ограничитель частоты запросов в памяти для разработки и основанный на Redis для продакшена. Edge Middleware Vercel может обрабатывать базовое ограничение частоты запросов. Upstash Redis (бесплатный уровень) с @upstash/ratelimit дает вам ограничение частоты запросов производственного качества с небольшим количеством кода.

Разумная отправная точка: 60 запросов в минуту для аутентифицированных пользователей, 20 в минуту для неаутентифицированных пользователей и 5 в минуту для конечных точек входа/регистрации (для предотвращения подбора паролей).

Время на исправление: 20–45 минут.

Ошибка 5: отсутствие проверок аутентификации на защищенных страницах и API

Как это происходит: AI генерирует красивую страницу панели управления и маршруты API, которые возвращают данные пользователя, но не добавляет промежуточный слой для проверки того, что пользователь действительно вошел в систему. Страница "работает", потому что во время разработки вы всегда вошли в систему. В продакшене кто-то может получить доступ к URL панели управления напрямую без входа, или обратиться к конечной точке API и получить данные обратно.

Почему это опасно: Неаутентифицированный доступ к защищенным страницам означает, что кто-либо может видеть панели управления пользователей, административные панели или приватные данные, просто угадав URL. Незащищенные маршруты API означают, что любой инструмент, такой как Postman или curl, может получить данные без учетных данных.

Как это обнаружить: Откройте окно инкогнито браузера (не вошли в систему) и перейдите прямо к вашей панели управления, настройкам или админ URL. Если вы видите любое содержимое без перенаправления на страницу входа, у вас есть эта проблема. Затем попытайтесь обратиться к вашим маршрутам API напрямую — если они возвращают данные без действительного cookie сеанса или токена аутентификации, эти маршруты также незащищены.

Исправление: Добавьте промежуточный слой аутентификации, который запускается перед каждым защищенным маршрутом. В Next.js App Router создайте middleware.ts в корне вашего проекта:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session');
  if (!session) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/settings/:path*', '/api/protected/:path*'],
};

Адаптируйте matcher, чтобы охватить каждый маршрут, требующий аутентификации. Протестируйте в инкогнито после реализации.

Время на исправление: 15–30 минут.

Как предотвратить это в будущих проектах

Картина ясна: AI генерирует функционально работающий код, но пропускает безопасность, потому что вы об этом не просили. Исправление заключается в том, чтобы попросить об этом с самого начала.

Добавьте это в конец вашего начального приглашения для любого вибрационного проекта:

SECURITY REQUIREMENTS:
- All secrets in environment variables (never hardcoded)
- Supabase RLS enabled on all tables with per-user policies
- Server-side input validation on every API route (use Zod)
- Rate limiting on all public endpoints
- Authentication middleware on all protected routes
- No service role key in client-side code

Это не поймает всё, но это устранит пять наиболее распространенных уязвимостей с первого раза, вместо того чтобы требовать очистки позже.

Если вы хотите лучше овладеть написанием приглашений, которые с самого начала создают более безопасный код, наш бесплатный оптимизатор приглашений может помочь вам структурировать ваши инструкции. И для полного руководства по безопасности см. наше пошаговое руководство: Как защитить вибрационное приложение перед отправкой его клиентам.

Раскрытие: некоторые ссылки в этой статье являются партнерскими ссылками. Мы рекомендуем только инструменты, которые мы лично протестировали и регулярно используем. См. нашу полную политику раскрытия информации.