Блок 5 · Урок 4 из 4

Валидация ввода и где горят чаще всего

Почему нельзя верить тому, что прислал пользователь, и какие дыры у вайб-кодеров встречаются чаще всего.

⏱ ≈ 8 минут 🔒 безопасность 🎯 цель: распознавать риск и правильно ставить задачу агенту

Зачем это вам

Большинство взломов и утечек данных происходят не потому, что хакер взломал сложную систему — а потому что приложение доверяло тому, что прислал пользователь, не проверив. Понимая термины «валидация», «санитизация», «SQL-инъекция» и «XSS», вы сможете разговаривать с агентом как грамотный заказчик: не просто «сделай безопасно», а «параметризируй запросы» и «экранируй вывод». А при приёмке приложения — задать правильные вопросы и увидеть, где горит.

Главный принцип

Никогда не доверяй пользовательскому вводу

Валидация ввода (input validation) — это проверка всего, что приходит в приложение извне: данные из форм, параметры в адресе страницы, ответы от чужих сервисов. Прежде чем использовать — проверить: тот ли тип данных, тот ли формат, разумная ли длина, допустимые ли значения.

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

📌 Золотое правило: всё, что пришло снаружи — из формы, из адресной строки, от другого сервиса — считать потенциально враждебным и проверять до использования.

Шесть дыр, где вайб-кодеры горят чаще всего

УязвимостьСутьКак просят закрыть
Секреты в коде1Ключи API утекают вместе с кодомВынести в .env, не коммитить
Нет проверки прав1Вошёл ≠ можно всё; чужое остаётся открытымПроверять авторизацию на каждом действии
SQL-инъекцияВвод попадает в запрос к базе как командаПараметры запроса или ORM
XSSЧужой скрипт исполняется у другого пользователяЭкранировать вывод перед вставкой в страницу
Доверие клиентуЦена или роль пришла из браузера — подменилиСчитать и проверять всё важное на сервере
Отладка в проде2Устаревшие зависимости и debug-режим в продакшенеРазделять dev/prod, обновлять пакеты

1 Подробнее — в уроках этого блока (0024 и 0025). 2 Разберём в блоках 6 и 7.

Аналогия, которую можно пересказать

Досмотр на входе: никому не верят на слово

Досмотр каждого на входе— валидация: проверять весь внешний ввод
Не верят на честное слово— никогда не доверяй пользовательскому вводу
Записка с приказом охране— SQL-инъекция: команда, протащенная под видом данных
Листовка для других посетителей— XSS: чужой скрипт в браузере другого пользователя
Поддельный пропуск прошёл— обход прав: забыли проверить авторизацию

Служба безопасности на входе не пропускает людей и сумки «на честное слово» — всё досматривают: тот ли документ, нет ли запрещённого. Валидация — это досмотр всего, что приходит в приложение. Если досмотра нет, пронесут что угодно. Правило одно: на входе не верят на слово — проверяют.

Запомните одно

Проверка в браузере — для удобства. Проверка на сервере — для безопасности.

Браузерная форма с ограничением «только цифры» — это подсказка пользователю, не замок. Злоумышленник её просто обойдёт. Настоящая защита живёт на сервере — там, куда не добраться через инструменты разработчика. Каждый раз, когда приложение что-то получает снаружи, оно обязано проверить это само, не рассчитывая на браузер.

Что это даёт на практике

Фраза агента → что он имеет в виду

«Добавлю валидацию ввода»
Буду проверять данные из форм и запросов перед использованием — тип, длину, допустимые значения.
«Параметризирую запрос»
Закрою SQL-инъекцию: данные передаются отдельно от команды и не могут стать кодом.
«Заэкранирую вывод»
Закрою XSS: чужой текст вставится как текст, а не как код — скрипт не исполнится.
«Это надо проверять на сервере»
Проверке в браузере доверять нельзя — её обходят. Только серверная проверка настоящая.

Валидация ввода (input validation) — проверка внешних данных перед использованием: тип, формат, длина, допустимые значения.

Санитизация / экранирование — обезвреживание ввода перед вставкой, например в страницу: спецсимволы превращаются в безопасный текст.

SQL-инъекция — внедрение команды в запрос к базе данных через необработанный ввод пользователя.

XSS (cross-site scripting, межсайтовый скриптинг) — внедрение чужого скрипта, который исполняется в браузере другого пользователя.

Проверьте себя

Четыре вопроса с мгновенной проверкой

1. Главное правило про пользовательский ввод?

2. Почему проверки в браузере недостаточно?

3. Что такое SQL-инъекция?

4. Вы принимаете приложение от агента. Что попросить проверить в первую очередь по безопасности?

Куда мы идём

Программа курса — 7 блоков