Безопасность сайта для вайбкодера: 4 дыры, которые надо закрыть

Что значит «защитить сайт» простыми словами

Твой сайт - это дом. Внутри твои вещи, данные пользователей, иногда их деньги. А теперь вообрази, что ты:

• написал пароль от сейфа маркером прямо на входной двери;
• врезал крутой замок, но ключ оставил торчать в скважине;
• пускаешь любого, кто буркнул «я свой», даже не глянув в лицо.

Дико? А именно так выглядит сайт, который сгенерил ИИ, если про безопасность ему не сказали ни слова. Агент по умолчанию делает так, чтобы работало. Не так, чтобы было безопасно. Это две разные задачи, и вторую надо просить отдельно.

Кому нужен мой маленький лендинг? Зачем вообще защищаться

«Я же просто делаю лендинг, кому я нужен?» - самая частая мысль новичка. И самая дорогая. А вот как на самом деле:

• Боты сканируют весь интернет круглые сутки. Им плевать, кто ты. Они ищут открытые двери автоматически - миллионами в час.
• Есть на сайте форма? Даже простое «оставьте email» - это уже точка входа.
• Утёк API-ключ API-ключ - секретный пароль, по которому твой сайт общается с другими сервисами: оплата, рассылки, ИИ. Если он утечёт, чужие будут тратить деньги от твоего имени. от платного сервиса - и чужие люди жгут твои деньги, пока ты сладко спишь.
• А утекли данные пользователей - это уже не «упс». Это штрафы, разборки и репутация в труху.

Хорошая новость: гуру кибербеза становиться не надо. Надо знать четыре главные дыры и уметь попросить агента их закрыть. Этим и займёмся.

Четыре главные дыры в безопасности сайта

У ECC есть скилл security-review - чек-лист, по которому агент проверяет код перед публикацией. Вытащим из него самое важное и самое частое.

1. Где хранить API-ключи и пароли (секреты)

Секрет Секрет - любой пароль, токен или ключ: доступ к базе данных, к платёжке, к API. Всё, что даёт власть над твоим сервисом. - это ключ от дома. Правило одно и простое: ключ не валяется внутри дома на виду.

Так делают новички (и так делать НЕ надо):

const apiKey = "sk-proj-xxxxx" - ключ вшит прямо в код. А код часто живёт в гите. Гит часто публичный. И всё - ключ уже не твой.

А как надо? Ключи лежат в отдельном файле (обычно .env.local), а в коде стоит только ссылка на него - process.env.OPENAI_API_KEY. И этот файл с ключами обязательно вписан в .gitignore, чтобы он никогда не уехал в гит.

2. Проверка ввода пользователя и загрузки файлов

Всё, что вводит пользователь - текст в форме, загруженный файл, адрес страницы - надо проверять, прежде чем что-то с этим делать. Правило в одну строку: не верь вводу по умолчанию.

Особенно это касается загрузки файлов. Есть у тебя «загрузите аватарку»? Тогда по чек-листу агент проверяет три вещи:

• размер - например, не больше 5 мегабайт. Иначе тебе зальют гигабайтный файл и аккуратно положат сервер;
• тип - только картинки: jpeg, png, gif. А не исполняемый файл-вирус, прикинувшийся котиком;
• расширение - .jpg, .png. А не .exe, которому пририсовали имя картинки.

И ещё одно правило из чек-листа: проверяй по белому списку («можно только вот это»), а не по чёрному («нельзя вот это»). Чёрный список всегда дырявый. Ты физически не перечислишь всё плохое на свете, а хакеру хватит одного пропущенного варианта.

3. Права доступа: проверяй на сервере, кому можно

Любимая ловушка новичков: «я просто спрятал кнопку удаления от обычных юзеров - значит, безопасно». Нет. Спрятать кнопку - это занавесить дверь шторкой. Кнопки не видно, но дверь открыта: кто знает адрес, тот войдёт.

А как правильно? Проверка на сервере перед каждым важным действием. Прежде чем удалить, изменить или показать чужие данные, код обязан спросить: «а у этого человека вообще есть право?» Например, перед удалением пользователя сервер сначала убеждается, что запрос идёт от админа, и только потом что-то трогает.

4. Безопасные ошибки и логи: не болтай лишнего

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

И зеркальное правило: в логи не должны попадать секреты. Не логируй пароли, номера карт, CVV и токены. Утечёт такой лог - и ты сам отдашь хакеру всё на блюдечке с голубой каёмочкой.

Безопасный сайт против дырявого: сравнение

Как взламывают сайт: пример из жизни

Собрал ты с агентом сайт-магазинчик: каталог, форма заказа, загрузка фото товара, оплата через сторонний сервис. Всё пашет, ты доволен, заливаешь на GitHub и публикуешь. А через два дня:

1. Прилетает счёт от платёжки на кучу денег - потому что ключ лежал прямо в коде, и боты выудили его из твоего публичного репозитория.
2. Сервер еле дышит - кто-то залил через «фото товара» огромные левые файлы, ведь размер и тип никто не проверял.
3. В админку зашёл посторонний - вся защита держалась на «ссылку не видно», а он просто угадал адрес /admin.

Ничего этого не случилось бы, попроси ты агента подумать о безопасности с самого начала. И вот как это сделать одним промптом:

Сделай security-review моего проекта перед публикацией. Проверь по чек-листу:

Секреты: нет ли паролей, API-ключей и токенов прямо в коде. Всё должно быть в .env.local, а сам .env.local - в .gitignore.
Ввод пользователя: проверяется ли весь ввод. Для загрузки файлов ограничь размер, тип и расширение по белому списку.
Права доступа: перед каждым важным действием (удаление, изменение, чужие данные) есть ли проверка прав на сервере, а не только спрятанная кнопка.
Ошибки и логи: пользователю показываются общие сообщения, в логи не попадают пароли и номера карт.
Покажи список найденных проблем простыми словами и предложи, как починить каждую.

Частые ошибки новичка в безопасности

• «Я никому не нужен». Боты сканируют всех подряд автоматически. Размер сайта тут вообще ни при чём.
• Ключ в коде плюс публичный гит. Классика жанра. Секреты - в .env.local, файл - в .gitignore.
• Защита «кнопку не видно». Спрятать в интерфейсе - не значит защитить. Проверка прав живёт на сервере.
• Форма принимает что угодно. Проверяй ввод и файлы по белому списку, а не на «авось пронесёт».
• Полный текст ошибки в лицо пользователю. Это карта для взломщика. Ему - «упс», подробности - в логи.
• Логировать пароли и карты. Утечёт лог - утечёт всё. Секретам в логах не место.
• Публиковать без ревью. Один промпт security-review ловит большинство детских дыр и стоит ноль рублей.