Часто задаваемые вопросы

Да. Полный список найденных рисков открыт бесплатно: вы видите направления, приоритет, evidence и базовое объяснение по каждому finding. Платное расширение (AI-слой) нужно не для открытия проблем, а для рекомендаций по исправлению, готовых формулировок документов и более прикладного ТЗ для команды.

Бесплатный слой показывает все найденные риски с приоритетом и базовым объяснением. AI-слой добавляет: готовые рекомендации по исправлению, формулировки для документов и cookie-блоков, прикладное ТЗ для команды и объяснение в бизнес-контексте. AI не влияет на то, какие риски найдены — только на глубину объяснения.

Обычно 2–5 минут. Система параллельно обходит до 24 ключевых страниц сайта и проверяет 576+ параметров: от политики ПДн и согласий до SEO/SSR, DNS-mail, security headers, WordPress-hardening и browser-level сценариев cookie/forms.

15 направлений и 576+ параметров публичного legal-first контура сайта:

• Юридические документы — наличие, содержание, ссылки на ПДн, cookie, оферту
• Формы и согласия — checkbox, привязка к кнопке «Отправить», скрытые поля
• Cookie и storage — загрузка трекеров до/после согласия, отзыв согласия
• Внешние сервисы — обработчики ПД, пиксели, рекламные сети
• Реквизиты и РКН — ИНН/ОГРН оператора, реестр Роскомнадзора
• Кибербезопасность — заголовки, открытые порты, admin-панели, SSL
• WordPress-hardening — раскрытие версий, авторские архивы, xmlrpc
• DNS-mail — SPF, DKIM, DMARC, защита от email-спуфинга
• SEO/SSR/Sitemap — canonical, индексация, ошибки рендеринга
• Контент и UGC — модерация отзывов, маркировка рекламы (ERID)
• Отраслевые риски — медицина, финансы, алкоголь, дети, казино

Любой публично доступный сайт с действующим доменом. Подходит для интернет-магазинов, лендингов, корпоративных сайтов, порталов и SaaS-сервисов. Сайты за паролем или во внутренних сетях недоступны для автоматического аудита.

ФЗ-152 «О персональных данных» обязывает любой сайт, собирающий данные пользователей (имена, email, телефоны), иметь Политику конфиденциальности, уведомить Роскомнадзор об операторе ПД и обеспечить согласие пользователей на обработку. Штраф за нарушение — до 100 000 ₽ за каждое нарушение, с 2024 года введена уголовная ответственность за утечку ПД.

Да, если сайт использует аналитические или рекламные cookie (Яндекс.Метрика, Google Analytics, пиксели ретаргетинга). По ФЗ-152 пользователь должен дать согласие до установки cookie, которые позволяют его идентифицировать. Технические cookie (сессия, корзина) согласия не требуют.

Политика конфиденциальности — основной документ, описывающий какие персональные данные собираются, как обрабатываются, хранятся и защищаются. Cookie-политика — отдельный документ, специфически описывающий какие cookie используются, зачем и как долго хранятся. Оба документа обязательны для сайтов, собирающих данные пользователей. Если в вашей Политике ПДн упоминается отдельная Cookie-политика, а страницы /cookies или /cookie-policy не существует — это юридическое противоречие.

Реестр операторов персональных данных Роскомнадзора — официальный список организаций и ИП, которые обрабатывают персональные данные. Уведомление обязательно для подавляющего большинства сайтов, собирающих любые данные пользователей (формы, email-подписки, онлайн-оплата). Аудит проверяет наличие вашего ИНН в реестре через публичный поиск РКН. Отсутствие в реестре — нарушение ч.1 ст.22 ФЗ-152. Подача уведомления бесплатна через pd.rkn.gov.ru.

Да, для коммерческих сайтов. Закон о защите прав потребителей обязывает указывать наименование организации, ИНН/ОГРН, юридический адрес и контактные данные. Для интернет-магазинов дополнительно требуются условия оплаты и доставки. Отсутствие реквизитов — основание для жалобы в Роспотребнадзор.

Зависит от нарушения: отсутствие Политики конфиденциальности — до 30 000 ₽ (ст. 13.11 КоАП); нарушение требований к обработке ПД — до 100 000 ₽; утечка ПД — до 15 млн ₽ (с 2024 г.); нарушение прав потребителей — до 500 000 ₽. Роскомнадзор может заблокировать сайт без предупреждения.

Это классическая ситуация frontend-only security: баннер есть, но трекеры (Яндекс.Метрика, пиксель ВКонтакте, Google Tag Manager) загружаются ещё до того, как пользователь нажал «Принять». В таком случае согласие — чисто декоративное. Аудит фиксирует именно технический факт загрузки трекеров до взаимодействия с баннером, а не само наличие баннера. Решение: настроить cookie-плагин на режим блокировки по умолчанию (Cookiebot, GDPR Cookie Consent) или реализовать условную загрузку через Tag Manager.

WordPress-плагины уведомлений о cookie (Cookie Notice, GDPR Cookie Consent и другие) по умолчанию ссылаются на отдельную страницу с Cookie-политикой. Если такой страницы нет (/cookies или /cookie-policy возвращают 404), баннер ссылается в никуда, а в документах сайта возникает противоречие. Аудит фиксирует это как документальную несостыковку средней степени серьёзности. Исправление: создать страницу /cookie-policy с перечнем используемых файлов, их сроками и назначением.

Стандартная WordPress-установка публично раскрывает служебную информацию:

• Авторский архив (/author/admin) — раскрывает логины пользователей системы
• XML-RPC (/xmlrpc.php) — устаревший протокол для brute-force атак
• Версия WordPress — позволяет таргетировать известные CVE
• wp-admin без доп. защиты — административная панель доступна всем

Ни одна из этих точек не является «уязвимостью» в классическом смысле — это hardening-проблемы: раскрытие информации, которая облегчает атаку. Исправление не требует срочности, но желательно: закрыть xmlrpc, отключить author-архив, скрыть версию WordPress.

Автоматический аудит работает только с публично доступными данными. Часть проверок требует контекста, который машина получить не может: например, содержание договора с обработчиком ПД, наличие ИНН в реестре РКН (сверка идёт по публичному поиску, который может лагать), или уточнение целевой аудитории сайта (нужна ли маркировка ERID). Такие находки выводятся как LOW с пометкой — это не ошибка движка, а честная граница автоматизации.

Аудит проверяет публичную доступность служебных точек: /wp-admin, /admin, phpMyAdmin, /bitrix/admin и аналогов. Если страница отвечает (200 или форма логина) без дополнительной защиты — это означает, что злоумышленник может таргетировать её перебором паролей. Рекомендация: ограничить доступ по IP (nginx allow/deny), добавить HTTP-аутентификацию или двухфакторную защиту на вход.

По ФЗ-152 и рекомендациям РКН пользователь должен иметь возможность отозвать согласие на cookie так же легко, как его дал. Если после закрытия/отклонения баннера трекеры продолжают работать (нет реальной технической блокировки), или кнопки «Только необходимые» / «Отклонить» не предусмотрены — это нарушение принципа добровольности согласия. Аудит проверяет наличие механизма revoke и признаки его технической работоспособности.

SSL/TLS — протокол шифрования данных между браузером и сервером (HTTPS). Без SSL браузеры помечают сайт как «небезопасный», поисковики снижают позиции, а передача форм с персональными данными по HTTP — прямое нарушение ФЗ-152. SSL-сертификат сегодня бесплатен (Let's Encrypt).

SPF (Sender Policy Framework) — DNS-запись, указывающая какие серверы вправе отправлять почту от имени вашего домена. DMARC — политика обработки писем, не прошедших SPF/DKIM-проверку. Без этих записей мошенники могут рассылать письма с вашего домена (email-спуфинг), что может повлечь попадание домена в чёрные списки и штрафы за несанкционированную рассылку.

X-Powered-By — HTTP-заголовок, который сервер отправляет автоматически: например, «X-Powered-By: PHP/8.1.2». Он раскрывает технологический стек, что позволяет злоумышленникам таргетировать известные уязвимости конкретной версии. Убрать просто: в nginx добавить proxy_hide_header X-Powered-By;, в PHP — expose_php = Off в php.ini.

Возможные причины:

• Документ находится по нестандартному URL (аудит ищет /privacy, /privacy-policy, /konfidentsialnost и другие типичные пути)
• Страница закрыта от индексации в robots.txt
• Ссылка на документ скрыта в JS-компоненте и не попала в анализ
• Сайт отдаёт страницу с кодом 200, но содержимое минимальное и не распознаётся как юридический документ

Проверьте: URL документа должен быть доступен без авторизации, содержать ключевые слова (персональные данные, обработка, оператор) и быть видимым в HTML-разметке страниц.

Аудит проверяет общедоступные порты публичного IP-адреса сайта. Порты баз данных (3306 MySQL, 5432 PostgreSQL), панелей управления (8080, 8888) или внутренних сервисов не должны быть открыты снаружи. Это не значит, что сервер взломан — но создаёт дополнительную поверхность атаки. Исправление: закрыть порты через UFW/iptables или ограничить доступ по IP для всего, кроме 80 и 443.

Аудит обращается к ряду специализированных публичных баз данных и API:

• Shodan InternetDB — открытые порты и известные CVE для IP-адреса сайта (бесплатный API, без ключа)
• FIRST EPSS — вероятность реальной эксплуатации каждой CVE (0..100%)
• CISA KEV — официальный каталог США «Known Exploited Vulnerabilities»: уязвимости, которые реально атакуются прямо сейчас
• AlienVault OTX — репутационные сигналы по домену и IP
• NIST NVD — база данных уязвимостей с CVSS-оценками
• Mozilla Observatory — проверка HTTP-заголовков безопасности
• Google PageSpeed — Core Web Vitals и производительность
• ФНС / ЕГРЮЛ / ДаДата — верификация оператора персональных данных
• РКН — реестр операторов персональных данных
• И ещё 14 источников: URLhaus, ThreatFox, Safe Browsing, PhishTank, CIRCL, HackerTarget и другие

Все источники работают параллельно и не являются точкой отказа — если один недоступен, остальные продолжают работу.

CISA KEV (Known Exploited Vulnerabilities) — это официальный список уязвимостей, которые реально используются хакерами прямо сейчас, подтверждённый Агентством кибербезопасности США (CISA). Если аудит показывает CVE из этого списка — это не просто теоретическая уязвимость. По директиве CISA BOD 22-01 все федеральные органы США обязаны закрывать KEV-уязвимости в приоритетном порядке. Для российских компаний это неформальный «красный флаг»: действуйте немедленно.

Дополнительно: каждой CVE показывается оценка EPSS — вероятность того, что в течение 30 дней появится рабочий эксплойт. EPSS > 50% означает: больше половины аналитиков ожидают публичного эксплойта.

Данные обновляются в реальном времени при каждом аудите. Кэширование применяется только для снижения нагрузки:

• Shodan InternetDB — 1 час
• CISA KEV каталог — 6 часов (обновляется несколько раз в день)
• EPSS оценки — 24 часа на CVE (FIRST.org публикует ежедневно)
• Репутационные базы (OTX, URLhaus, ThreatFox) — кэш от 30 минут до 6 часов

При повторном аудите через сутки вы получите актуальные данные с учётом новых публикаций в CISA KEV и изменений EPSS-оценок.

Каждый внешний API-источник, который мы используем, находится под постоянным мониторингом:

• Реестр интеграций — каждый источник задокументирован: URL, требования к авторизации, ограничения частоты, заметки по безопасности
• DNS-пининг — мы фиксируем IP-адрес каждого API-эндпоинта и получаем уведомление, если он меняется
• SSL fingerprint — SHA256 сертификата каждого API пинуется и перепроверяется
• Schema проверка — при каждой проверке отправляется тестовый запрос и валидируется формат ответа
• Еженедельный cron — каждое воскресенье в 02:00 запускается полная проверка всех 23+ интеграций
• Авто-карантин — если источник дважды подряд не прошёл проверку, он автоматически отключается
• Bundle integrity — SHA256 хэш продакшн-кода фиксируется и сравнивается при каждом деплое

Это не стандартная практика для SaaS-сервисов — мы ввели её как фундаментальное правило для защиты пользователей.