Под input validation мы понимаем проверку любых данных, поступающих от пользователя, перед их использованием. Это самый основной и часто упускаемый слой защиты. Многие разработчики думают "я доверяю пользователю" или "я проверил на front-end, хватит". На самом деле оба варианта неверны. Пользователю нельзя доверять никогда, а проверка на front-end легко обходится атакующим.
Whitelist vs Blacklist — что правильно?
В валидации существуют два основных подхода: whitelist (список разрешенных) и blacklist (список запрещенных). В blacklist вы пишете "эти символы опасны, я их отклоняю". Но этот подход очень слабый — потому что нельзя знать все опасные символы. Атакующие всегда находят новые способы. А в whitelist вы говорите "я разрешаю только эти символы". Этот подход гораздо безопаснее. Например, для номера телефона разрешаете только цифры и знак "+". Для email используете специальную функцию filter_var().
Server-side валидация обязательна
Проверка на front-end через JavaScript полезна, но только для улучшения пользовательского опыта. С точки зрения безопасности она ничего не дает. Потому что атакующий может отключить JavaScript в браузере или отправить HTTP запрос напрямую. Поэтому каждая валидация должна повторяться на стороне сервера. Это выглядит как двойная работа, но обязательно. Без server-side валидации никакая программа не может быть безопасной.
Валидация по типам данных
Каждый тип данных имеет свои правила валидации. Для email используется filter_var($email, FILTER_VALIDATE_EMAIL). Для URL — FILTER_VALIDATE_URL. Для чисел — is_numeric() или ctype_digit(). Для даты — класс DateTime. Для номера телефона — проверка через regex, например для номера Узбекистана "^\+998[0-9]{9}$". Также нужно проверять длину — слишком длинный текст тоже может быть угрозой (атака denial of service).
Загрузка файлов — особая опасность
Файлы, загруженные пользователем, один из самых больших источников опасности. Нельзя доверять только расширению файла — атакующий может назвать .php файл с расширением .jpg. Поэтому нужно проверять тип файла через mime type. Кроме того, ограничивать размер файла, изменять имя файла (простая случайная строка), хранить файл вне web root. И самое важное — настроить конфигурацию сервера так, чтобы загруженный файл не запускался как PHP.
Сообщения об ошибках валидации
Когда валидация не удалась, нужно четко сказать пользователю, что не так. Но сообщения об ошибках не должны давать лишнюю техническую информацию. Например, "Email в неправильном формате" — хорошее сообщение. Но "SQLSTATE[23000]: Integrity constraint violation" — плохое — это дает атакующему информацию о структуре базы данных.
Практика Sayt.uz
На платформе Sayt.uz каждая форма проверяется на стороне сервера. Email, телефон, надежность пароля, тип и размер файла — все проверяется подходом whitelist. Для пользовательского опыта добавлена и front-end валидация, но она никогда не является единственной защитой. Разместив свой сайт на хостинге Sayt.uz, можно обеспечить полную безопасность через домен и SSL сертификат.