В идеальном мире ТЗ на разработку сайта составляет системный аналитик. В суровой реальности малого и среднего бизнеса этим часто занимается маркетолог, потому что больше просто некому.

Раньше я тоже была в этой лодке: писала требования, совершала классические ошибки новичка и молилась, чтобы разработка не встала. Обходилось, но нервы трепали знатно. Сегодня мой подход изменился. 15 лет опыта в маркетинге плюс профильное обучение на системного аналитика дали свой результат: теперь я знаю, как составить грамотное ТЗ, которое разработчики поймут с полуслова, а не будут мучить десятками уточняющих вопросов.

Но для маркетологов‑новичков этот небольшой чек‑лист по ФОС, надеюсь, будет полезен.

Форма обратной связи — это «входная дверь» в компанию. Если ее не защищать, то прилетит ответка:

  • Утечка данных клиентов — штрафы по 152-ФЗ (в России) или GDPR (в Европе) до 4% годового оборота;

  • Спам‑атака через форму — падение домена в репутации, письма от твоего домена попадают в спам, а поисковые системы «пессимизируют» твой сайт;

  • Фальшивые заявки — отдел продаж тратит время на «липовые» лиды, портится статистика;

  • Подмена контента — на сайте появляются левые ссылки или вирусы.

Ты как маркетолог не обязан настраивать это технически. Но ты обязан прописать эти требования в ТЗ, чтобы разработчик их выполнил, а потом — проверить результат.

На что обязательно нужно обратить внимание маркетологу при написании ТЗ для сайта и формы обратной связи:

  • HTTPS (SSL‑сертификат) — обязательно

    • Что требовать в ТЗ:
      Форма должна работать только через HTTPS. Все данные (имя, телефон, email, сообщение) должны передаваться в зашифрованном виде

    • Как проверить:
      В адресной строке браузера — замок. Если нет замка — форма небезопасна

      Проверка протокола https
      Проверка протокола https

Текст в ТЗ: Страница с формой обратной связи должна быть доступна только по протоколу HTTPS. При переходе по HTTP должен выполняться автоматический редирект (301) на HTTPS‑версию

  • Защита от автоматической отправки (капча / honeypot)

    • Что требовать в ТЗ:
      Обязательная защита формы от автоматических отправок. Минимальный уровень — honeypot или reCAPTCHA v3

    • Виды защиты (от простых к сложным):

      1. Honeypot (скрытое поле, которое заполняют только боты) — просто, не мешает пользователю (всегда нужно проверять на корректность отработки формы после установки — иногда «косячит» с отправкой формы в СРМ)

      2. reCAPTCHA v2 («я не робот») — эффективно, но раздражает

      3. reCAPTCHA v3 (невидимая, оценивает поведение) — лучший баланс

        reCAPTCHA v2
        reCAPTCHA v2

Форма должна быть защищена от автоматических отправок с использованием [выбрать: один из вариантов выше]. При превышении лимита отправок с одного IP (например, 5 заявок в минуту) форма должна временно блокироваться на 1 час для пользователя.

  • Валидация полей на стороне сервера
    Злоумышленник может отправить в поле «Имя» не текст, а HTML‑код или JavaScript. Если разработчик сделал валидацию только в браузере (на стороне клиента), этот код попадет в CRM или в письмо менеджеру.

    • Что требовать в ТЗ:
      Все поля должны проверяться на сервере. Пользователь не должен иметь возможность отправить теги HTML, JavaScript или SQL‑команды.

    • Разрешить:
      Только буквы, цифры, пробелы, знаки препинания (нужный набор описать)

Текст в ТЗ: Валидация полей формы должна выполняться на стороне сервера (не только в браузере). Допустимые символы в поле «Имя»: только буквы, пробел, дефис. Поле «Телефон»: только цифры, +, пробел, скобки. Все HTML‑теги и JavaScript‑код должны экранироваться (превращаться в безопасный текст).

Как проверить это самостоятельно? Очень просто. Введи в поле «Имя» на сайте вот такой тестовый код: <script>alert('test')</script>. Отправь форму, а затем открой письмо, которое пришло менеджеру. Или загляни в CRM. Если защита работает правильно, ты увидишь там просто этот набор символов как обычный текст. А вот если на экране выскочило всплывающее окно — значит, сайт уязвим

  • Ограничение длины полей
    Без ограничения длины злоумышленник может отправить в поле «Сообщение» 1 миллион символов, что может перегрузить и положить сервер.

    • Что требовать в ТЗ:
      Для каждого поля указать максимальную длину (на сервере, не только в браузере).

    • Пример (почти всегда этого достаточно):
      Имя: 50 символов, Email: 100 символов, Телефон: 20 символов, Сообщение: 2000 символов.

Текст в ТЗ: Для каждого поля формы заданы следующие ограничения длины (проверка на сервере): например, 55. При превышении длины форма возвращает понятную пользователю ошибку.

Как проверить самостоятельно: Попробуй отправить в поле «Имя» текст длиной 100 символов. Форма должна выдать ошибку.

  • Email‑проверка: не любой текст с собачкой
    Даже через поле email можно получить email‑инъекцию, что может привести к подмене получателя.

    • Что требовать в ТЗ:
      Проверка формата email по RFC 5322 (на сервере) + запрет частых отправок с одного email.

    • Что проверяем:
      Наличие @ и точки после @, отсутствие пробелов, запрет спецсимволов кроме разрешенных.

Текст в ТЗ: Поле «Email» должно проходить проверку формата на сервере. Допустимый шаблон: локальная_часть@домен.зона (без пробелов, запрещены символы < > ( ) [ ];: «). Один email‑адрес может отправить не более 3 заявок в час.»

Как проверить самостоятельно: Попробуй отправить test@test — ошибка. Отправь test@test.com — ок.

  • Логирование без сохранения чувствительных данных
    Логи сервера и база данных формы часто хранят всё, что отправил пользователь. Если лог попал к злоумышленнику — он получит телефоны, email‑ы, тексты сообщений. Это нарушение закона (152-ФЗ / GDPR).

    • Что требовать в ТЗ:
      Логи должны храниться только необходимое время (например, 30 дней). Паспортные данные, детали платежей, пароли — не логировать вообще.

    • Что запретить в логах:
      Номер телефона (или маскировать: +7******1234) Точный текст сообщения (хранить только в защищенной CRM).

Текст в ТЗ: В логах веб‑сервера и базы данных не должны сохраняться: полный номер телефона, точный email, текст сообщения (только факт отправки). Для этих данных используется маскировка. Срок хранения логов — не более 30 дней.

Как проверить самостоятельно: Попросите разработчика показать структуру таблицы в БД, куда попадают данные из формы. Убедись, что нет полей с открытыми телефонами в логах.

  • Согласие на обработку данных (галочка)
    Без явного согласия пользователя — штрафы до 4% оборота (GDPR) или до 500 тыс. руб. (152-ФЗ). Пользователь должен знать, что с его данными будут делать, и добровольно согласиться.)

    • Что требовать в ТЗ:
      Чекбокс «Я согласен на обработку моих персональных данных» — активным его сделать нельзя. Ссылка на политику конфиденциальности — обязательна.

    • Минимальный набор:
      Текст согласия (конкретный, без «и так далее»). Ссылка на страницу с политикой конфиденциальности. Чексбокс без предустановленной галочки.

Текст в ТЗ: Рядом с кнопкой отправки размещен чекбокс с текстом: «Я соглашаюсь на обработку моих персональных данных в соответствии с [ссылка на Политику конфиденциальности]». Чекбокс по умолчанию не отмечен. Отправка формы возможна только при его активации.

  • Отправка дополнительных файлов
    Чтобы обезопасить заливку к вам на сервер каких‑то скрытых скриптов, лучше прописать ограничения для разработчика заранее.

    • Что требовать в ТЗ:
      Проверка типа файла (только jpg/png/pdf/word), проверка размера (не более 2–5 MB).

    • Что проверять:
      антивирусная проверка, переименование файла перед сохранением.

      Прикрепление дополнительного файла к форме
      Прикрепление дополнительного файла к форме

Плохое ТЗ — это всегда деньги на ветер и подпорченные нервы: бюджет уходит на переделки, время — на бесконечные согласования. Репутация страдает из‑за багов на сайте.

Хорошее ТЗ работает как ваша личная страховка. Оно спасает маркетолога и гарантирует, что на выходе бизнес получит именно тот инструмент, который нужен, без неприятных сюрпризов. Поэтому тот чек‑лист для формы обратной связи, который я дал выше, лучше реально учесть в работе

Если тема будет интересна маркетологам, то продолжим с других разделов ТЗ;)