Любая форма на сайте содержит атрибут action, однозначно определяющий куда именно отправляются данные формы после заполнения ее пользователем и это обычный URL документа сайта, который как правило осуществляет обработку данных формы (сохранение в базу, отправка письма, поиск по сайту, изменения данных и пр.). Пользователь не видит данный адрес и попадает на страницу обработки только по клику на кнопке отправки. Очень часто при этом на сайте осуществляют проверку факта заполнения формы актуальными требуемыми данными таким образом, что не заполнив нужные поля формы, у пользователя нет шансов осуществить отправку.
Однако, любые роботы, сканирующие страницу (не только поисковые системы, которых несколько десятков, но и любые роботы, осуществляющие сбор данных по сети – их тоже несколько десятков может быть замечено на сайте), не производят заполнение формы и отправку данных, но пытаются «попасть» на страницу, принимающую данные формы. Вот почему они просто запрашивают тот документ, адрес которого содержится в форме, и фактически «переходят» на него в обход формы и всех проверок на ее заполнение.
Такой несанкционированный переход может приводить к «срабатыванию» обработки данных, которых по факту нет. Как результат в базу сайта могут попадать «пустые» данные, если форма отправляет данные по почте – могут приходить «пустые» письма без содержания.
Для того, чтобы «отсечь» такие ложные срабатывания, рекомендуется делать несколько дополнительных проверок в сценарии обработки данных формы, а именно:
- Проверять HTTP-метод запроса формы – GET или POST. Если форма передает данные методом POST (указывается в атрибуте method тега form), то обработку данных нужно проводить только, если документ запрашивается «правильным» методом. Естественно, что большинство роботов будут запрашивать документ обработки формы стандартным методом GET.
- Проверка данных формы по всем критериями (по наличию обязательных данных, по формату данных и пр.) должна также осуществляться и на серверной стороне. Т.е. не только самом форма, используя JavaScript осуществляет проверку для пользователя, но и на стороне сервера сценарий обработки данных полностью повторяет данную проверку. Т.о. если данные пришли не полные или не соответствующие требованиям – обработка не производится и пользователю выдается ошибка.
- Необязательная, но и очень важная часть – это проверка на безопасность данных, на то, что данные заполнялись именно на вашем сайте, а не пришли с другого ресурса. Для этого недостаточно как правило проверять содержимое HTTP-заголовка referer, лучше использовать защиту от такого типа атак (CSRF) на основе специального токена, который содержится на странице формы в специальном скрытом поле и является уникальным для каждого запроса страницы формы. Сценарий обработки данных при этом должен проверять правильность данного токена и обрабатывать их только после того, как токен подтвержден. Подробнее см. ru.wikipedia.org/wiki/Межсайтовый_скриптинг