Штрафы за авторизацию на сайте в 2026 году: что проверить владельцу сайта

Почему в 2026 году владельцам сайтов стоит проверить авторизацию

Раньше многие владельцы сайтов относились к авторизации как к обычной функции: поставить плагин соцвхода, разрешить регистрацию через email, добавить кнопку Google или Apple ID и не возвращаться к этому годами.

В 2026 году ситуация изменилась. Требования к способам авторизации пользователей на российских интернет-ресурсах связаны с 149-ФЗ «Об информации, информационных технологиях и о защите информации». Изменения в эту часть регулирования были внесены Федеральным законом от 31.07.2023 №406-ФЗ, а в 2026 году появилась административная ответственность за нарушение правил авторизации.

Для владельца сайта это означает простую вещь: если на сайте есть вход пользователя, его нужно проверить. Не только кнопку в шапке, но и все технические сценарии: регистрацию, восстановление пароля, личный кабинет, checkout, комментарии, AJAX-обработчики, API endpoints и старые плагины.

Я смотрю на эту задачу как технический специалист: не как юрист, который выдаёт заключение, а как разработчик, который помогает найти очевидные слабые места в авторизации и привести сайт к более безопасной схеме входа.

Что изменилось в законе

149-ФЗ установил требования к способам авторизации

Базовая логика требований связана с 149-ФЗ. Если владелец интернет-ресурса проводит авторизацию пользователей, находящихся в России, он должен использовать установленные способы авторизации.

К таким способам относятся:

• российский номер телефона;
• ЕСИА, то есть «Госуслуги»;
• ЕБС, единая биометрическая система;
• российская информационная система авторизации, соответствующая требованиям закона.

На практике для большинства обычных коммерческих сайтов самый обсуждаемый вариант — не ЕСИА и не ЕБС, а российские ID-провайдеры и собственная схема входа с дополнительными ограничениями.

406-ФЗ внёс изменения раньше, но штрафы появились позже

Федеральный закон от 31.07.2023 №406-ФЗ внёс изменения, после которых владельцам сайтов пришлось обращать внимание на способы авторизации. Но долгое время для малого и среднего бизнеса эта тема воспринималась как отложенный риск: требование есть, но вопрос ответственности был менее заметен.

Из-за этого на многих сайтах до сих пор остались старые сценарии:

• вход через Google;
• вход через Apple ID;
• вход через Facebook;
• регистрация через иностранную почту;
• старые плагины социального входа;
• формы, которые визуально убрали, но технически не отключили.

Законопроект №1069392-8 и закон №199-ФЗ добавили ответственность

Законопроект №1069392-8 был принят Госдумой во втором и третьем чтениях 9 июня 2026 года. Затем Федеральный закон от 26.06.2026 №199-ФЗ внёс изменения в КоАП.

Главное изменение для владельцев сайтов: в КоАП появилась ответственность за неисполнение обязанности проводить авторизацию пользователей установленными способами.

Именно поэтому тему авторизации теперь нельзя воспринимать как чисто теоретическую. Если раньше владелец сайта мог годами не проверять, как именно устроен вход, то теперь стоит провести технический аудит.

Какие штрафы предусмотрены

За первое нарушение предусмотрены следующие штрафы:

Кто нарушил	Штраф за первое нарушение
Физические лица	10 000–20 000 ₽
Должностные лица	30 000–50 000 ₽
Юридические лица	500 000–700 000 ₽

За повторное нарушение штрафы выше. Для юридических лиц сумма может доходить до 1,4 млн ₽.

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

То есть пользователь, который когда-то вошёл через Gmail или Apple ID, не становится нарушителем. Риск находится на стороне владельца ресурса, который такую схему входа оставил доступной.

Кого это касается

Проверить авторизацию стоит не только крупным сервисам. На практике риск может быть и у обычного сайта на WordPress, 1С-Битрикс, OpenCart, Joomla, Drupal, MODX, Tilda или у самописного PHP-проекта.

Проверка нужна, если на сайте есть:

• регистрация пользователей;
• интернет-магазин;
• личный кабинет;
• форум или сообщество;
• комментарии только после входа;
• избранное;
• список желаний;
• история заказов;
• подписки;
• закрытые разделы;
• обучающая платформа;
• кабинет ученика;
• кабинет партнёра;
• мобильное приложение;
• веб-сервис;
• CRM-доступ для клиентов;
• вход через внешние сервисы.

Иногда владелец сайта уверен, что «у нас авторизации нет», но потом выясняется, что она есть в WooCommerce, LMS-плагине, модуле отзывов, личном кабинете, партнёрском разделе или старом popup-окне.

Что считается рискованной авторизацией

Вход через иностранные OAuth-сервисы

Первое, что нужно проверить, — вход через зарубежные сервисы. Обычно это:

• Google;
• Apple ID;
• Facebook;
• GitHub;
• Discord;
• Microsoft Account;
• старые OAuth-провайдеры из плагинов;
• универсальные плагины social login, где включено всё подряд.

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

Регистрация через иностранную почту

Отдельный спорный и чувствительный участок — регистрация через иностранную почту. С технической стороны владельцу сайта стоит проверить, как именно используется email:

• как обычный логин в собственной базе сайта;
• как подтверждение через письмо;
• как вход через внешний почтовый сервис;
• как часть OAuth-сценария;
• как единственный идентификатор пользователя.

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

Старые плагины и самописные формы

Риск часто находится не в новом коде, а в старом:

• плагин соцвхода поставили несколько лет назад и забыли;
• WooCommerce добавил регистрацию на checkout;
• комментарии требуют входа;
• в мобильной версии осталась отдельная форма;
• AJAX endpoint принимает запросы напрямую;
• REST API продолжает обслуживать старый сценарий;
• форма входа удалена из меню, но shortcode остался на скрытой странице;
• старый обработчик доступен по прямому URL.

Поэтому проверка должна быть не визуальной, а технической.

Что проверить на сайте

Видимые точки входа

Начать можно с интерфейса. Проверьте:

• шапку сайта;
• кнопку «Войти»;
• popup входа;
• страницу регистрации;
• страницу авторизации;
• личный кабинет;
• страницу «Мой аккаунт»;
• checkout;
• комментарии;
• избранное;
• восстановление пароля;
• мобильную версию;
• футер;
• скрытые страницы, которые не видны в меню.

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

Технические обработчики

После интерфейса нужно смотреть backend:

• URL авторизации;
• URL регистрации;
• AJAX endpoints;
• REST API endpoints;
• callback URL от OAuth-провайдеров;
• старые redirect URI;
• активные плагины social login;
• неактивные, но оставленные файлы;
• кастомные PHP-обработчики;
• mu-plugins;
• functions.php;
• обработчики темы;
• обработчики дочерней темы.

Если на сайте WordPress, нужно проверить не только стандартные /wp-login.php и /wp-admin/, но и плагины, которые создают собственные формы входа. У WooCommerce, LMS-плагинов, membership-плагинов, форумов и плагинов комментариев могут быть отдельные сценарии авторизации.

Старые аккаунты и роли

Отдельный пункт — старые пользователи. Если раньше люди входили через Google или Apple ID, нужно понять, что будет после отключения этого способа.

Проверьте:

• есть ли у пользователей email;
• есть ли резервный способ входа;
• смогут ли они восстановить пароль;
• не потеряют ли доступ администраторы;
• есть ли старые роли, созданные плагинами;
• есть ли технические аккаунты;
• не завязана ли авторизация администратора на внешний сервис.

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

Какие есть варианты решения

Вариант 1. Белые списки email-доменов

Для небольших сайтов иногда логично начать с белых списков email-доменов. Это техническая настройка, при которой сайт разрешает регистрацию и вход только по заранее определённым доменам.

Например, можно настроить:

• список разрешённых email-доменов;
• запрет регистрации с нежелательных доменов;
• отдельные правила для администраторов;
• отдельные правила для клиентов;
• текст ошибки при неподходящем email;
• журнал попыток регистрации;
• резервный сценарий восстановления доступа.

Такой вариант подходит для сайтов, где не нужна массовая регистрация через соцсети, а вход используется для комментариев, избранного, личного кабинета или закрытого раздела.

Плюс этого подхода — он не требует SMS-интеграции. Минус — нужно аккуратно продумать список доменов и сценарии для старых пользователей.

Вариант 2. VK ID + резервный способ входа

VK ID — один из практичных вариантов для сайтов, которым нужен внешний российский ID-провайдер. Его можно использовать как основной способ входа или как один из разрешённых способов.

При настройке важно проверить:

• корректный OAuth flow;
• redirect URI;
• callback URL;
• обработку ошибок;
• привязку старых пользователей;
• создание новых пользователей;
• роли по умолчанию;
• защиту от дублей аккаунтов;
• резервный способ входа для администратора.

Я не рекомендую оставлять сайт без резервного сценария. Если внешний провайдер временно недоступен, владелец сайта должен иметь безопасный способ попасть в админку и управлять ресурсом.

Вариант 3. Яндекс ID + VK ID + резервный способ

Для части проектов удобнее комбинированная схема: Яндекс ID + VK ID + резервный способ входа.

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

Технически здесь нужно настроить:

• два российских ID-провайдера;
• понятный выбор способа входа;
• привязку аккаунтов;
• проверку дублей;
• fallback-сценарий;
• отдельные права для администраторов;
• тексты форм;
• обработку ошибок;
• тестирование на мобильной версии.

Важно не превращать форму входа в хаос. Чем больше вариантов авторизации, тем выше риск ошибок, дублей и конфликтов между плагинами.

Почему SMS — не всегда лучший первый шаг

Один из разрешённых вариантов — авторизация по российскому номеру телефона. Но для небольших сайтов SMS почти всегда означает дополнительные расходы.

Нужно учитывать:

• стоимость SMS;
• договор с провайдером;
• лимиты;
• защиту от накрутки кодов;
• повторную отправку;
• хранение номера телефона;
• обработку персональных данных;
• сценарии для пользователей без доступа к номеру.

Поэтому для небольшого сайта часто логичнее сначала рассмотреть белые списки email-доменов или российские ID-провайдеры: VK ID, Яндекс ID и резервный способ входа.

Это не универсальный рецепт. Для крупного сервиса, маркетплейса или приложения с массовой регистрацией SMS может быть оправданным вариантом. Но для обычного сайта услуг, блога с комментариями, интернет-магазина или закрытого раздела нужно считать стоимость и сложность поддержки.

Почему нельзя просто убрать кнопку Google или Apple ID

Кнопка в интерфейсе — это только видимая часть авторизации.

Если вы просто удалили кнопку из шапки, это не значит, что старый сценарий отключён. На сайте может остаться:

• backend-обработчик;
• callback URL;
• endpoint плагина;
• shortcode на старой странице;
• AJAX-действие;
• REST-маршрут;
• ссылка в мобильном меню;
• форма в кэше;
• старая страница входа;
• доступ через прямой URL.

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

Что делать владельцу сайта

Шаг 1. Найти все формы входа

Проверьте не только главную страницу. Авторизация может быть в личном кабинете, checkout, комментариях, избранном, закрытых разделах, мобильной версии и старых страницах.

Шаг 2. Проверить провайдеры

Составьте список всех способов входа:

• email и пароль;
• Google;
• Apple ID;
• Facebook;
• GitHub;
• Discord;
• VK ID;
• Яндекс ID;
• SMS;
• ЕСИА;
• кастомный вход;
• вход через плагин.

Если вы не можете быстро составить такой список, это уже повод для технического аудита.

Шаг 3. Отключить иностранные OAuth-сценарии

Недостаточно снять галочку в визуальной настройке. Нужно проверить, что старый endpoint действительно перестал принимать запросы, а callback URL больше не работает.

Шаг 4. Настроить разрешённые способы входа

В зависимости от сайта можно выбрать:

• белые списки email-доменов;
• VK ID;
• Яндекс ID;
• VK ID + Яндекс ID;
• российский номер телефона;
• резервный способ для администратора;
• отдельную схему для старых пользователей.

Шаг 5. Обновить тексты форм

Пользователь должен понимать, как теперь входить на сайт. Проверьте:

• текст на форме входа;
• текст регистрации;
• ошибки при неподходящем email;
• письмо восстановления пароля;
• уведомления для старых пользователей;
• страницу личного кабинета.

Шаг 6. Протестировать старых пользователей

Перед включением новой схемы проверьте:

• вход существующего клиента;
• восстановление пароля;
• вход администратора;
• вход менеджера;
• регистрацию нового пользователя;
• регистрацию с неподходящим email;
• вход с мобильного телефона;
• оформление заказа;
• комментарии;
• избранное.

Шаг 7. Обновить пользовательские документы

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

• политику конфиденциальности;
• пользовательское соглашение;
• согласия;
• тексты на формах;
• описание способов входа;
• документы по персональным данным.

Я не заменяю юридическую проверку, но могу подготовить техническое описание: какие способы входа были, какие отключены, какие включены и где это работает на сайте.

Шаг 8. Проверить рекомендательные технологии

Рядом с темой авторизации есть ещё один риск — рекомендательные технологии.

Если на сайте есть рекомендации, похожие материалы, персональные подборки, алгоритмические блоки, «вам может понравиться», «с этим товаром смотрят», «похожие статьи», «рекомендуемые услуги» или персональная выдача, стоит отдельно проверить:

• используются ли рекомендательные алгоритмы;
• есть ли информирование пользователей;
• размещены ли правила применения рекомендаций;
• указаны ли контактные данные владельца ресурса;
• не создаёт ли блок рекомендаций дополнительные риски.

Это отдельная задача, но её удобно проверять вместе с аудитом авторизации, потому что оба вопроса относятся к владельцу интернет-ресурса и его технической реализации.

Что я могу проверить как технический специалист

При аудите авторизации я обычно смотрю не только видимую форму входа, но и технические следы старых сценариев.

Проверяю:

• активные способы входа;
• плагины авторизации;
• OAuth-настройки;
• callback URL;
• REST API;
• AJAX endpoints;
• регистрацию пользователей;
• восстановление пароля;
• роли пользователей;
• личный кабинет;
• checkout;
• комментарии;
• мобильную версию;
• старые страницы;
• кэш;
• редиректы;
• тексты форм;
• сценарии для старых пользователей.

После проверки можно выбрать практичный вариант настройки: белые списки email-доменов, VK ID, Яндекс ID + VK ID, резервный вход для администратора или комбинированную схему.

Техническая настройка снижает очевидные риски, но не является юридической гарантией отсутствия претензий или штрафов.

Чеклист владельца сайта

Проверьте:

• есть ли на сайте регистрация;
• есть ли личный кабинет;
• есть ли вход в комментарии;
• есть ли избранное или список желаний;
• есть ли checkout с созданием аккаунта;
• есть ли подписки или закрытые разделы;
• есть ли вход через Google;
• есть ли вход через Apple ID;
• есть ли вход через Facebook;
• есть ли вход через GitHub;
• есть ли вход через Discord;
• есть ли старый social login plugin;
• есть ли регистрация через иностранную почту;
• есть ли скрытые страницы входа;
• есть ли AJAX endpoints для авторизации;
• есть ли REST API endpoints для входа;
• есть ли callback URL от старых OAuth-провайдеров;
• есть ли резервный вход для администратора;
• смогут ли старые пользователи войти после изменений;
• обновлены ли тексты форм;
• обновлены ли пользовательские документы;
• есть ли на сайте рекомендательные блоки;
• есть ли информирование о рекомендательных технологиях, если они используются.

Нужна проверка авторизации на сайте?

Если на сайте есть регистрация, личный кабинет, комментарии, избранное или вход через внешние сервисы, я могу проверить текущую авторизацию и предложить безопасный вариант настройки: белые списки, VK ID или Яндекс ID + VK ID.

Работаю с WordPress, 1С-Битрикс, OpenCart, Joomla, Drupal, MODX, Tilda и самописными PHP-проектами.

Материал не является юридическим заключением. Я помогаю с технической частью: найти старые способы входа, отключить рискованные сценарии, настроить новую схему авторизации и подготовить сайт к более аккуратной работе с пользователями.