#полезно Не верьте фронту на слово. Валидация на фронте ≠ Безопасность Представим ситуацию: все как обычно, дизайнер надизайнил форму регистрации (да-да, пример банальный, но через него и суть легче донести), фронтендер добавил валидацию полей, всё красиво, кнопки покрашены, формочки нашлепаны и показываются понятные ошибки. Мы идем проверять - вроде и работает, и спецсимволы требует к паролю, и имейл неправильный не введешь... Двинули таску дальше, все гуд! А потом в проде кто-то регистрируется с email длиной в 10 000 символов, или засовывает в поле "имя" SQL-инъекцию, или отправляет отрицательное количество товара в заказе А, что, так можно было?: Валидация на фронте - это про удобство и скорость. Сразу вижу, когда ввёл email без собаки, когда прибор пароль короткий, телефон не по формату. Не нужно отправлять запрос на сервер и ждать ответ, перезагружать страницу, слава богу, уже не в моде. Быстро, приятно, но не надежно Бэкенд валидация - это про то, что система не сломается, и данные останутся консистентными. Потому что клиент - это ненадёжная среда. Всегда. Раньше, любой, кто умел открывать DevTools, мог пройти собес спокойно. А сейчас, в эпоху развитого ютюба и в особенности нейросетей может: - Отключить JavaScript с валидацией - Отключить CSS стиль, блокирующий кнопку (обычно, это какой-то класс, да еще и с понятным названием) - Перехватить запрос и изменить данные перед отправкой - сниффер трафика никто не запрещал - В конце концов использовать скрипт, который отправляет запросы напрямую в апишку, минуя фронтенд вообще У меня на работе действительно был кейс, где это сделал просто клиент. Но мы не знаем, баг ли на клиенте, логи не нашли, но подозрение, что он умеет пользоваться постманом... Это не обязательно злоумышленник, причины могут быть разные: - Баг в клиентском коде, который отправил кривые данные - Старая версия мобильного приложения с устаревшей валидацией - Интеграция с апишкой от третьей стороны - Просто любопытный тестировщик, который проверяет безопасность (да, это ты!) Давай на простом примере: Допустим у нас есть запрос, обновляющий почту апишка для обновления профиля принимает что-то типа: { "userId": 12345, "email": "new@email.com" } В данном случае, фронтенд сам подставляет userId текущего залогиненного юзера. Но что мешает изменить это поле на 12346 и обновить чужой профиль? Если бэк не проверяет, что userId из токена авторизации совпадает с userId в запросе - это IDOR (Insecure Direct Object Reference) уязвимость! Или вот еще один: Калькулятор стоимости услуги на фронте считает итоговую сумму и отправляет её на бэк. Да, можно поменять 15000 на 150 - это конечно, вряд ли сработает (Не дай бог сработает). Но интереснее еще и другое: бизнес-логика расчёта лежит в двух местах (фронт и бэк). Когда меняются правила расчёта, можно забыть обновить одну из сторон и тогда фронт показывает одну цену, а бэк списывает другую - вот такой кейс уже более реальный. Поэтому нормальная практика такая: фронт помогает пользователю, бэк не верит никому. Всё, что влияет на деньги, доступы, права и данные, считается валидным только после проверки на сервере. А пока логика размазана между фронтом и бэком баги будут появляться «из ниоткуда». Один расчёт забыли обновить, одну проверку продублировали, одну вообще пропустили. И в итоге система делает ровно то, что ей позволили.