Валидация формы на клиенте: почему нельзя полагаться только на javascript

6 минут чтения

Форму на сайте проверяйте сначала средствами HTML5, затем при необходимости дополняйте JavaScript, а перед обработкой обязательно повторяйте проверку на сервере. Клиентская валидация помогает быстро показать ошибку, но её можно обойти или отключить. Поэтому надёжная схема сочетает ограничения полей, понятные сообщения, доступность и серверные правила.

Опорные принципы проверки формы

Используйте HTML-атрибуты required, type, minlength и pattern для простых ограничений.
Показывайте ошибку рядом с полем и сообщайте, как исправить значение.
Оставляйте браузерную проверку включённой; JavaScript должен дополнять её, а не заменять.
Проверяйте данные на сервере независимо от результатов в браузере.
Связывайте поля, подсказки и ошибки семантической разметкой.
Проверяйте отправку клавиатурой, при отключённом JavaScript и с некорректными данными.

Начните с ограничений HTML5: required, type и pattern

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

Электронная почта

Не стоит полагаться только на pattern для сложных бизнес-правил, проверять по нему сведения, требующие обращения к базе данных, или считать успешную проверку в браузере доказательством корректности. Синтаксис HTML-атрибутов может ограничить формат, но не подтверждает, например, что адрес действительно принадлежит пользователю.

Показывайте ошибки рядом с полем и объясняйте, как их исправить

До реализации согласуйте поведение формы и подготовьте доступы к проекту. Для работы понадобятся:

перечень полей, обязательных значений и допустимых форматов;
описание правил обработки на сервере и требований к сохраняемым данным;
доступ к HTML-шаблону и JavaScript-коду формы;
среда для проверки отправки и просмотра серверных ответов;
тексты подсказок и ошибок, написанные понятным пользователю языком.

Сообщение должно называть проблему и способ исправления: например, "Введите адрес в формате name@example.com". Не полагайтесь только на цвет рамки: оставьте видимый текст ошибки и обозначьте поле, к которому он относится.

Дополняйте встроенную проверку JavaScript-логикой без подмены браузерных механизмов

JavaScript нужен для дополнительных условий и более удобной обратной связи. Не отключайте проверку HTML5 атрибутом novalidate, если не реализовали равноценное поведение самостоятельно. Для проверки используйте браузерный API checkValidity() или reportValidity().

Опишите правила и состояния формы.
Зафиксируйте, какие поля обязательны, какие форматы допустимы и при каких условиях отправка запрещена. Отделите эти правила от текста сообщений и обработки отправки.
Задайте встроенные ограничения.
Добавьте полям подходящие типы и атрибуты, например type="email", required или minlength. Это даст базовую проверку до выполнения дополнительного кода.
Добавьте проверку специальных условий.
Если правило зависит от нескольких полей, проверяйте его JavaScript-кодом и устанавливайте состояние через setCustomValidity(). Сбрасывайте пользовательское сообщение, когда значение становится допустимым.
Покажите ошибку и сохраните нативное поведение.
При отправке проверьте форму и укажите, что именно нужно исправить; после ошибки переведите фокус к первому некорректному полю. Не скрывайте подсказки браузера без замены на доступный текст.
Проверьте отправку.
Убедитесь, что корректные данные доходят до сервера, а некорректные не обрабатываются. Повторите тест с отключённым JavaScript и при изменённых вручную данных запроса.

Быстрый режим

Добавьте нужные HTML-ограничения и подписи полей.
Покажите понятное сообщение около каждого поля с ошибкой.
Дополните проверку JavaScript только для правил, которых нет в HTML.
Повторите все проверки на сервере и протестируйте форму без JavaScript.

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

Проверяйте те же данные на сервере перед обработкой

Сервер должен считать входящие данные недоверенными: запрос можно отправить напрямую, минуя интерфейс и JavaScript. До сохранения, отправки уведомления или другого действия проверьте допустимые значения и типы данных по правилам приложения.

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

Учитывайте доступность: связывайте подсказки, ошибки и поля формы

При проверке доступности ищите прежде всего такие ошибки:

У поля нет видимой подписи или она не связана с ним через for и id.
Сообщение об ошибке размещено далеко от соответствующего поля.
Об ошибке сообщают только цветом, без текста.
После неудачной отправки фокус не помогает найти первое поле, требующее исправления.
Подсказка или ошибка не связана с полем через aria-describedby.
Для некорректного поля не установлен атрибут aria-invalid="true" после проверки.
Сообщение исчезает до того, как пользователь успевает его прочитать.
Поля и сообщения нельзя последовательно пройти с клавиатуры.

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

Проверьте сценарии отправки, обхода проверок и работы без скриптов

Выберите подход в соответствии с задачей:

Нативные ограничения HTML. Подходят для простых форм с обязательными полями и стандартными форматами.
HTML и JavaScript. Используйте, когда нужны зависимые поля, дополнительные правила или более подробная обратная связь; браузерные ограничения при этом сохраняются.
Проверка на сервере. Обязательна во всех вариантах, если данные влияют на сохранение, расчёт, уведомления или доступ к функции.

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

Практические нюансы валидации веб-форм

Можно ли оставить только проверку HTML5?

Для простых форм HTML5 ограничений может хватить на клиенте. Серверная проверка всё равно обязательна, если данные обрабатываются или сохраняются.

Зачем нужна серверная проверка, если поля уже проверяет браузер?

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

Когда использовать JavaScript-валидацию?

Используйте её для дополнительных правил, зависящих от нескольких полей, или для более удобного показа обратной связи. Не делайте JavaScript единственным местом, где задано обязательное правило.

Стоит ли убирать сообщения браузера?

Не отключайте их, если не предусмотрели доступную и понятную замену. Используйте встроенные механизмы браузера или обеспечьте собственные сообщения, фокус и связь ошибок с полями.

Как сообщить пользователю, что исправить?

Укажите поле, причину ошибки и конкретное действие: например, предложите ввести адрес электронной почты в нужном формате. Размещайте сообщение рядом с полем.

Как понять, что форма работает без JavaScript?

Отключите скрипты и отправьте форму с тестовыми данными. Пользователь должен иметь возможность пройти сценарий, а сервер - отклонить некорректный ввод и вернуть объяснение.

Защищает ли валидация от спама?

Нет, проверка формата и обязательных полей не останавливает злоупотребления сама по себе. Защитные меры нужно проектировать и проверять отдельно.

Автор: Алексей Воронов

Post Views: 0