Чек-лист безопасности сайта: 47 пунктов от практика — что проверить за час
47 пунктов проверки безопасности за час без специального ПО. HTTPS, OWASP Top 10, утечки, инфраструктура. С командами и инструкциями. Закрывает 80% типовых брешей.
Коротко (TL;DR)
- 47 пунктов разделены на 5 разделов: HTTPS и сертификаты, веб-уязвимости (OWASP Top 10), аутентификация и сессии, информационные утечки, инфраструктура и обновления.
- Каждый пункт — с конкретной командой/инструментом проверки и шагами фикса. Проверяется за час без специального ПО.
- Закрывает 80% типовых проблем безопасности веб-сайтов. Оставшиеся 20% требуют профессионального пентеста и аудита кода.
- Если хоть один пункт не выполнен — у вас есть уязвимость. Большинство брешей в РФ-сегменте 2024-2026 — из этого списка.
- Нужен полный аудит безопасности под ключ — закажу аудит от 15 000 ₽, отчёт за 1-3 дня с приоритетами и инструкциями по исправлению.
Зачем самопроверка и чем она отличается от пентеста
За 2024-2026 я внедрял безопасность в десятках проектов — от лендингов до b2b SaaS на 10 000 пользователей. Видел все типичные дыры. И давно убедился: 80% инцидентов в РФ-сегменте — это базовые ошибки, которые владелец мог бы найти сам за час, без специального ПО, без хакера-консультанта за 200 000 ₽.
Этот чек-лист — для собственника сайта, технического директора, разработчика, который хочет понять «у нас вообще нормально с безопасностью или мы голые». Не заменяет профессиональный пентест — это глубокое тестирование с эксплуатацией уязвимостей, оно нужно для банков, медицины, госуслуг, КИИ. Но 80% сайтов в РФ не доходят даже до этого базового уровня — и именно из-за этого утекают в новости.
Что нужно для прохождения: браузер с DevTools, доступ к терминалу (Windows/Linux/macOS), 60-90 минут времени. Опционально — онлайн-сервисы вроде SSL Labs, securityheaders.com, hstspreload.org. Если хоть один из 47 пунктов не выполнен — это уязвимость, которая может стать инцидентом.
Раздел 1: HTTPS и сертификаты (пункты 1-8)
Если HTTPS настроен криво — все остальные меры безопасности обесцениваются, потому что трафик можно перехватить и подменить.
1. HTTPS включён на всём сайте без mixed content
Каждая страница, каждый скрипт, каждое изображение должны грузиться по HTTPS. Один HTTP-ресурс на странице (mixed content) — и браузер показывает предупреждение, а у вас есть точка для MITM-атаки.
Как проверить
curl -I https://example.com
# открыть сайт в Chrome, F12 -> Console
# смотреть на предупреждения "Mixed Content"
# или https://www.whynopadlock.com/Что делать если плохо: найти все ссылки http:// в HTML/JS/CSS, заменить на https:// или относительные. Добавить заголовок Content-Security-Policy: upgrade-insecure-requests.
2. HSTS заголовок установлен корректно
HTTP Strict Transport Security говорит браузеру «никогда не открывай этот сайт по HTTP». Защищает от SSL stripping. Минимум: max-age=31536000; includeSubDomains. Идеально: preload.
Как проверить
curl -sI https://example.com | grep -i strict-transport
# должно быть:
# strict-transport-security: max-age=31536000; includeSubDomains; preloadЕсли нет: добавить в конфиг nginx/Apache/CDN. Перед включением preload — убедиться, что ВСЕ субдомены работают по HTTPS, иначе они станут недоступны.
3. Сертификат не просрочен и не истекает в ближайшие 30 дней
Истёкший сертификат = сайт недоступен. Установите автообновление и мониторинг.
Как проверить
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# или https://www.ssllabs.com/ssltest/Если плохо: Let's Encrypt с certbot — автообновление каждые 60 дней. Платный сертификат — настроить алерт в мониторинге за 30 дней до окончания.
4. TLS версии 1.2 и выше, никаких 1.0/1.1/SSL 3
Старые версии TLS содержат известные уязвимости (BEAST, POODLE). Многие платёжные системы (PCI DSS) уже требуют только TLS 1.2+.
Как проверить
nmap --script ssl-enum-ciphers -p 443 example.com
# или https://www.ssllabs.com/ssltest/ — отчёт ProtocolsЕсли плохо: в nginx — ssl_protocols TLSv1.2 TLSv1.3;. В Apache — SSLProtocol -all +TLSv1.2 +TLSv1.3.
5. Cipher suites без слабых алгоритмов
RC4, DES, 3DES, MD5, NULL-шифры — давно сломаны. Должны быть выключены.
Как проверить
nmap --script ssl-enum-ciphers -p 443 example.com | grep -E "RC4|DES|MD5|NULL|EXPORT"
# должно быть пустоЕсли плохо: использовать рекомендации Mozilla SSL Configuration Generator (intermediate или modern).
6. HTTP редиректит на HTTPS
Запрос на http://example.com должен возвращать 301 на https://example.com, не показывать страницу по HTTP.
Как проверить
curl -I http://example.com
# ожидаем: HTTP/1.1 301 Moved Permanently
# Location: https://example.com/Если плохо: в nginx — отдельный server-блок на 80 порту с return 301 https://$host$request_uri;
7. www и non-www ведут себя одинаково
Либо оба варианта доступны, либо один редиректит на другой 301-м кодом. Иначе SEO раздваивается, а пользователи путаются.
Как проверить
curl -I https://example.com
curl -I https://www.example.com
# оба должны быть 200 или 301 в одну сторону8. Certificate Transparency: нет посторонних сертификатов на ваш домен
Если кто-то выпустил сертификат на ваш домен через скомпрометированный CA — это видно в CT-логах. Регулярно проверяйте.
Как проверить
# открыть в браузере: https://crt.sh/?q=example.com
# просмотреть все выданные сертификаты, найти неизвестныеЕсли найдены чужие: срочно связаться с CA для отзыва, провести аудит инфраструктуры.
Раздел 2: Веб-уязвимости — OWASP self-check (пункты 9-23)
OWASP Top 10 — список самых распространённых уязвимостей. Каждая из них — минимум одна громкая утечка в новостях каждый месяц.
9. SQL-инъекции
Самая древняя и до сих пор самая распространённая уязвимость. Позволяет читать/менять базу через web-формы.
Как проверить
В любое поле ввода (логин, поиск, фильтр) попробовать: ' OR 1=1 -- или ';DROP TABLE users-- или ' UNION SELECT NULL --.
Если получили ошибку SQL, странный результат, попали в админку — уязвимы.
Что делать: использовать prepared statements / ORM везде. Никаких конкатенаций строк с пользовательским вводом в SQL-запросы.
10. XSS — Cross-Site Scripting
Внедрение JS-кода через поля ввода. Позволяет красть куки, перенаправлять пользователей, выполнять действия от их имени.
Как проверить
В каждое поле ввода: <script>alert(1)</script> или "><img src=x onerror=alert(1)>. Если alert сработал на странице — уязвимы.
Что делать: экранировать вывод (HTML escape, JS escape, URL escape — в зависимости от контекста). Установить Content-Security-Policy. Не использовать innerHTML с пользовательскими данными — только textContent.
11. CSRF — Cross-Site Request Forgery
Атака, при которой чужой сайт от имени залогиненного пользователя выполняет действия на вашем сайте. Защита — CSRF-токены.
Как проверить
В DevTools найти любую POST-форму. Проверить: есть ли в hidden-полях токен (csrf_token, _token, X-CSRFToken)? Если форма принимает запрос без токена — уязвимы.
Что делать: добавить CSRF-токен во все формы изменения состояния. Куки с SameSite=Lax закрывают 90% CSRF, но токены всё равно нужны для защищённости.
12. IDOR — Insecure Direct Object Reference
Доступ к чужим данным через подмену ID в URL: /orders/123 → /orders/124. Если сервер не проверяет, что заказ 124 принадлежит вам — утечка данных.
Как проверить
Залогиниться двумя пользователями. От первого открыть свой ресурс с ID. Поменять ID на чужой. Если открылось — уязвимы.
Что делать: на каждый запрос проверять права доступа на уровне БД (WHERE user_id = current_user_id). Использовать UUID вместо инкрементальных ID — снижает вероятность угадывания.
13. Path traversal
Доступ к файлам ОС через подмену путей: ?file=../../etc/passwd.
Как проверить
В параметрах GET, которые принимают имя файла: ../../../../etc/passwd, ..\..\..\windows\win.ini. Если в ответе системный файл — уязвимы.
Что делать: белый список разрешённых имён файлов. Использовать абсолютные пути из чистой папки. Не давать пользователю напрямую указывать имя файла.
14. Command injection
Выполнение команд ОС через web. Если ваш код вызывает shell с пользовательским вводом — катастрофа.
Как проверить
В поля, которые могут передаваться в утилиты (поиск, обработка файлов, ping): ; ls -la, | whoami, && cat /etc/passwd.
Что делать: не использовать exec/system/shell_exec с пользовательским вводом. Если без shell нельзя — белый список команд, экранирование через shlex.quote (Python) или аналоги.
15. SSRF — Server-Side Request Forgery
Сервер делает запрос на URL, который указал пользователь. Атакующий может обратиться к внутренней сети: http://localhost:22, http://169.254.169.254/ (метаданные облака).
Как проверить
Если есть форма «вставьте ссылку на картинку/сайт» — попробовать http://127.0.0.1/, http://169.254.169.254/latest/meta-data/. Получили внутреннюю информацию — уязвимы.
Что делать: белый список разрешённых доменов. Блокировать приватные IP-диапазоны (10.x, 172.16-31.x, 192.168.x, 127.x, 169.254.x).
16. XXE — XML External Entity
Если ваш сайт принимает XML-загрузки — может быть уязвим. XXE позволяет читать локальные файлы и делать SSRF.
Как проверить
Загрузить XML с внешней сущностью: <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo>.
Что делать: отключить внешние сущности в XML-парсере. В Python — defusedxml. В Java — XMLConstants.FEATURE_SECURE_PROCESSING.
17. Open redirect
Параметр ?next=... или ?redirect=..., через который можно отправить пользователя на phishing-сайт от имени вашего домена.
Как проверить
В параметре редиректа: ?next=https://evil.com/. Если редиректит — уязвимы.
Что делать: белый список разрешённых URL для редиректов. Или относительные пути только (/dashboard, не https://...).
18. Insecure deserialization
Если в куках или параметрах есть base64-закодированные объекты — попробовать их изменить. На многих стеках (PHP, Java, Python pickle) это приводит к RCE.
Как проверить
Открыть DevTools → Application → Cookies. Если cookies выглядят как base64 — декодировать, изменить, заэкодировать обратно. Если сайт принимает изменённое — уязвимы.
Что делать: подписывать сериализованные данные (HMAC). Не использовать pickle/yaml.load для пользовательских данных — только JSON.
19. JWT — типичные ошибки
Если используете JWT — проверить: алгоритм none, weak secret, отсутствие проверки expiration.
Как проверить
Декодировать JWT на jwt.io. Если алгоритм HS256 — попробовать none и проверить, примет ли сервер. Попробовать сбрутить secret через hashcat (jwt.secrets.list).
Что делать: белый список алгоритмов (только RS256 или HS256 с длинным секретом). Проверять expiration. Не хранить чувствительные данные в JWT — он не зашифрован.
20. CORS не слишком разрешающий
Заголовок Access-Control-Allow-Origin: * с Allow-Credentials: true — комбинация, при которой любой сайт может читать данные ваших залогиненных пользователей.
Как проверить
curl -I -H "Origin: https://evil.com" https://example.com/api/user
# смотрим Access-Control-Allow-Origin в ответеЧто делать: белый список конкретных доменов в CORS. Никаких звёздочек на endpoint, требующих авторизации.
21. CSP — Content Security Policy
Заголовок, ограничивающий, откуда могут грузиться скрипты/стили/изображения. Защищает от XSS даже при наличии уязвимости.
Как проверить
curl -sI https://example.com | grep -i content-security
# или https://csp-evaluator.withgoogle.com/Что делать: начать со строгого default-src 'self' и постепенно разрешать что нужно. Избегать unsafe-inline и unsafe-eval.
22. X-Frame-Options — защита от clickjacking
Без этого заголовка ваш сайт можно вставить в iframe на чужом сайте и обмануть пользователя на клик.
Как проверить
curl -sI https://example.com | grep -i x-frame-options
# должно быть: X-Frame-Options: DENY (или SAMEORIGIN)23. Referrer-Policy настроен правильно
Без этого заголовка ваш сайт может «протекать» полные URL в Referer наружу — а в URL могут быть токены сессии.
Как проверить
curl -sI https://example.com | grep -i referrer-policy
# рекомендую: strict-origin-when-cross-originНе уверены, что закрыли все 23 пункта правильно?
Заберу аудит безопасности под ключ от 15 000 ₽. Прогоню 47 пунктов лично, найду что упустили, дам отчёт с приоритетами (критично / важно / косметика) и инструкциями по исправлению. По NDA по умолчанию, никаких публичных раскрытий. Срок 1-3 дня.
Раздел 3: Аутентификация и сессии (пункты 24-32)
Самая частая мишень атак — пользовательский логин. Если здесь дыра, остальные защиты не помогут.
24. Куки с HttpOnly, Secure, SameSite=Lax
Сессионная кука должна быть недоступна JS (HttpOnly), передаваться только по HTTPS (Secure), не отправляться cross-site (SameSite=Lax или Strict).
Как проверить
curl -sI https://example.com/login
# найти Set-Cookie, проверить флаги
# или DevTools → Application → Cookies25. Сессии истекают по таймауту
Бессрочная сессия — это украденная кука работает вечно. Должен быть idle timeout (30 мин — 24 ч) и absolute timeout (7-30 дней).
26. Логин не подсказывает «такой пользователь не существует»
Сообщения должны быть унифицированными: «Неверный логин или пароль». Отдельные сообщения позволяют атакующему перебрать список пользователей.
Как проверить
Попробовать логин с заведомо несуществующим email и существующим email + неверным паролем. Если сообщения отличаются — уязвимо. То же касается формы «забыли пароль» и регистрации.
27. Brute-force защита
После 5-10 неудачных попыток — captcha или временная блокировка IP/аккаунта.
Как проверить
Попробовать 20 раз войти с неверным паролем. Если форма продолжает работать без замедлений/captcha — уязвимо.
Что делать: rate-limit на уровне приложения (например, Flask-Limiter) и/или Cloudflare/nginx rate-limiting.
28. 2FA доступно (или обязательно для админов)
Двухфакторная аутентификация — TOTP (Google Authenticator), не SMS (SIM-swap). Для админ-аккаунтов — обязательно.
29. Сброс пароля через одноразовую ссылку
Не через SMS (SIM-swap), не через email с новым паролем в открытом виде. Ссылка на сброс — одноразовая, истекает за 15-60 минут.
30. Пароли хранятся хешированными (bcrypt/argon2/scrypt)
Не MD5, не SHA-1, не SHA-256 без соли. Только адаптивные функции — bcrypt, argon2, scrypt.
Как проверить
Запросить у разработчика образец записи пользователя из БД. Если password выглядит как $2b$12$... (bcrypt) или $argon2id$... — отлично. Если 32-символьный hex (MD5) или 64-символьный (SHA-256 без соли) — катастрофа.
31. Минимальная длина пароля 12+
NIST 800-63B 2024 рекомендует минимум 8, лучше 12-15. Запрещать пароли из топ-10000 утёкших (haveibeenpwned password list).
32. Сессия инвалидируется при смене пароля
Если кто-то украл сессию, а вы поменяли пароль — все старые сессии должны прекратиться, включая активные на других устройствах.
Раздел 4: Информационные утечки (пункты 33-40)
Часто атакующие даже не ищут уязвимости — просто берут то, что вы случайно выложили в публичный доступ.
33. /robots.txt не содержит секретные пути
Парадокс: некоторые админы пишут Disallow: /admin/secret-panel в robots.txt — и тем самым публикуют эту ссылку.
Как проверить
curl https://example.com/robots.txt
# любые упоминания админок, бэкапов, dev-эндпоинтов — плохо34. /.git/ не доступна публично
Самая частая катастрофа: при деплое через git pull папка .git остаётся в webroot и любой может скачать всю историю кода (с паролями, ключами, секретами).
Как проверить
curl -I https://example.com/.git/config
# должно быть 403 или 404, не 200Если 200: срочно закрыть в nginx/apache. Деплоить через git push, не git pull в webroot.
35. /.env, /config.php, /wp-config.php не отдают 200
Файлы с секретами должны быть недоступны через web.
Как проверить
for p in .env config.php wp-config.php .htpasswd backup.sql database.sql ; do
curl -o /dev/null -w "%{http_code} $p\n" https://example.com/$p
done36. Stack traces не показываются в production
Если при ошибке пользователь видит полный stack trace с путями файлов, версиями фреймворка, фрагментами кода — это утечка инфраструктуры.
Как проверить
Спровоцировать ошибку: невалидный параметр, несуществующий ID, SQL-инъекция, переполнение поля. Должна показаться красивая страница 500, не дамп.
Что делать: в Django — DEBUG = False. В Flask — обрабатывать исключения через errorhandler. В PHP — display_errors = Off.
37. Server header не выдаёт версию
Заголовок Server: Apache/2.4.41 (Ubuntu) сообщает атакующему точную версию для подбора эксплойтов.
Как проверить
curl -sI https://example.com | grep -i "^server:"
# хорошо: nginx, или вообще скрыт
# плохо: nginx/1.18.0, Apache/2.4.4138. X-Powered-By скрыт
Аналогично: X-Powered-By: PHP/7.4.3 или X-Powered-By: Express — лишняя информация для атакующего.
39. Версии CMS/фреймворка не в HTML-исходнике
WordPress в meta-тегах генерирует <meta name="generator" content="WordPress 5.8.1">. Любая CMS — аналогично. Скрыть.
Как проверить
curl -s https://example.com | grep -i "generator\|version"40. /sitemap.xml не утекает dev/staging-страницы
Часто в sitemap случайно попадают draft-страницы, тестовые URL, дев-эндпоинты. Проверить вручную.
Раздел 5: Инфраструктура и обновления (пункты 41-47)
Базовая гигиена сервера. Без этого все остальные меры — впустую.
41. Все зависимости обновлены, нет известных CVE
Старые версии npm/pip/composer пакетов — главный источник уязвимостей в современных приложениях.
Как проверить
# Node.js
npm audit
# Python
pip-audit
# PHP
composer audit
# Docker-образы
docker scan myimage:latest
# или https://snyk.io/, GitHub DependabotЧто делать: настроить Dependabot/Renovate на автоматическое создание PR с обновлениями. Раз в неделю мерджить.
42. SSH доступ только по ключу, root отключён
В /etc/ssh/sshd_config: PasswordAuthentication no, PermitRootLogin no. Только ключи. Только не-root пользователи.
43. Открыты только необходимые порты
80, 443 — для HTTP/HTTPS. 22 — SSH, ограничен по IP (или Cloudflare Tunnel/wireguard). Всё остальное закрыто.
Как проверить
nmap -p- -T4 example.com
# или с самого сервера: ss -tlnp44. Бэкапы существуют и проверены восстановлением
Бэкап, который никогда не восстанавливали — это не бэкап, а файл. Минимум раз в квартал — учения по восстановлению.
45. Мониторинг и алерты
Логи доступа (access.log) + анализ. Алерты на: всплеск 404 (сканер), всплеск 500 (что-то ломается), необычная активность на админке.
46. WAF включён
Cloudflare, BotFAQtor, российские WAF от Selectel/VK Cloud. Блокирует базовые атаки до того, как они дойдут до приложения.
47. План реагирования на инциденты записан
Кто звонит кому, в каком порядке, что отключаем первым, как уведомляем РКН про утечку (24 часа по 152-ФЗ). Документ из 1 страницы. Подробнее в статье про утечки и 24 часа.
Что делать если нашли уязвимости: приоритезация
Не пытайтесь закрыть всё сразу — расставьте приоритеты. Моя классификация по 3 уровням:
Критично (закрыть за 24-48 часов): SQL-инъекция (#9), XSS на админке (#10), пароли plaintext (#30), доступная /.git/ (#34), HTTPS без HSTS (#1, #2), пароли через MD5 (#30), открытые админ-эндпоинты без авторизации, отсутствие 2FA на админах (#28). Эти пункты — взлом за один день.
Важно (за 1-2 недели): CSRF (#11), IDOR (#12), JWT-проблемы (#19), CORS-ошибки (#20), отсутствие brute-force защиты (#27), устаревшие зависимости с known CVE (#41), SSH с паролями (#42), отсутствие мониторинга (#45). Эти пункты — взлом при целенаправленной атаке.
Косметика (за месяц): Server header (#37), X-Powered-By (#38), generator-теги CMS (#39), некоторые информационные утечки. Не критично, но любой security-аудитор отметит.
В часах работы для среднего сайта: критичное — 8-20 часов, важное — 20-60 часов, косметика — 5-15 часов. Итого 1-3 человеко-недели на полную зачистку.
Когда нужен профессиональный аудит и пентест
Этот чек-лист закрывает 80% типовых проблем. Оставшиеся 20% — это сложные многошаговые уязвимости, бизнес-логика, race conditions, недостатки в крипто, цепочки атак через несколько компонентов. Их находит только профессиональный пентест с глубоким анализом.
Кому обязательно нужен профессиональный аудит:
- Банки и финтех. Регуляторные требования ЦБ + ОУПД, PCI DSS для приёма карт.
- Медицина и здравоохранение. Особо чувствительные ПД, ФЗ-323, штрафы выше базовых.
- Объекты КИИ (критическая информационная инфраструктура). 187-ФЗ, обязательный пентест.
- Госуслуги и работа с госорганами. ГИС, ФСТЭК-требования.
- Крупные e-commerce (от 100k активных клиентов). Утечка таких баз — миллиардные оборотные штрафы по ст. 13.11 КоАП (с 30 мая 2025).
- B2B SaaS с обработкой клиентских данных. SOC 2, ISO 27001 при выходе на международные рынки.
Цена профессионального пентеста — от 150 000 ₽ за быстрый аудит до 2-5 млн ₽ за полноценный red team с социальной инженерией. Для большинства средних бизнесов хватает гибрида: моя самопроверка по чек-листу за 1-3 дня (от 15 000 ₽), и раз в год полный пентест от специализированной компании.
Частые вопросы
Я проверил все 47 пунктов — гарантирован ли я от взлома?
Нет, гарантия 100% защиты невозможна. Этот чек-лист закрывает базу — 80% типовых атак, через которые взламывают 90% сайтов. Останутся: zero-day-уязвимости в фреймворках, целевые атаки от продвинутых злоумышленников, социальная инженерия с вашими сотрудниками, инсайдеры. Безопасность — это процесс, не состояние.
Сколько стоит профессиональный пентест?
В РФ 2026: быстрый аудит периметра — от 80-150 тыс ₽, полноценный black box пентест веб-приложения — 250-600 тыс ₽, white box с доступом к коду — 400-1200 тыс ₽, red team с социалкой и физическим проникновением — 2-5 млн ₽. Срок: от 2 недель до 2 месяцев. Делается известными компаниями (Positive Technologies, Bi.Zone, Group-IB, Сайбер Альфа) или хорошими независимыми пентестерами.
Я нашёл уязвимость на чужом сайте — что делать?
Responsible disclosure: написать владельцу или в security-команду компании, описать проблему, дать 60-90 дней на исправление, после этого можно публиковать. Не эксплуатировать уязвимость — это статья 272/273 УК РФ независимо от мотивации. Не публиковать публично до исправления — иначе помогаете злоумышленникам.
Достаточно ли Cloudflare для защиты сайта?
Cloudflare закрывает DDoS, базовые WAF-сигнатуры, частично — bot-атаки. Не закрывает: уязвимости в коде приложения (SQL, XSS, IDOR), неправильную аутентификацию, утечки через открытые файлы, инсайдерские угрозы. Cloudflare плюс этот чек-лист — хорошая база. Только Cloudflare — иллюзия защищённости.
Как часто нужно перепроверять чек-лист?
Базовый прогон — раз в квартал. После каждого крупного релиза (изменения архитектуры, добавление компонентов) — повторить релевантные пункты. Сразу после инцидента у конкурентов из вашей ниши — тоже не помешает. Полный пентест — раз в год минимум, для регулируемых отраслей — раз в полгода.
Что такое responsible disclosure?
Этичный подход к раскрытию уязвимостей. Исследователь сообщает владельцу системы, договариваются о сроках исправления (обычно 60-90 дней), затем публично описывается уязвимость (часто уже после исправления). Альтернатива — bug bounty программы, где компании платят за найденные уязвимости (Yandex, VK, Сбер, Tinkoff/Т-Банк, Ozon — все имеют программы в РФ).
Как защититься от ботов и парсеров?
Cloudflare Bot Management или ваш WAF — первая линия. Rate-limiting на API. Captcha (hCaptcha, Cloudflare Turnstile) на критичных формах. Honeypot-поля в формах (скрытые поля, которые заполняются только ботами). Анализ поведения (скорость кликов, паттерны движения мыши) — для продвинутых решений. Полностью защититься нельзя, но усложнить жизнь массовым парсерам — можно.
Выводы
Если ваш сайт прошёл все 47 пунктов — вы в топ-20% защищённости в РФ. Если 35-45 — нормальный средний уровень, базовые угрозы закрыты. Если меньше 35 — у вас есть серьёзные дыры, нужно срочно закрывать критичные пункты, иначе вопрос «когда взломают» а не «взломают ли».
Что делать прямо сейчас:
- Прогоните чек-лист по своему сайту. Минимум — раздел 1 (HTTPS) и раздел 4 (утечки) — это закрывается за 2-3 часа.
- Если нашли критичное (SQL-инъекция, открытая /.git/, пароли plaintext) — отложите остальное и закрывайте это сегодня.
- Заведите регулярный процесс: ежеквартальный прогон чек-листа, ежегодный профессиональный пентест.
- Подготовьте план реагирования на инциденты — кому звонить, что отключать, как уведомлять РКН (24 часа на уведомление об утечке по 152-ФЗ).
Если разбираетесь сами — этот чек-лист достаточен для большинства задач. Если нужна помощь с аудитом, расследованием инцидента или внедрением мер безопасности — пишите. Работаю с NDA, никаких публичных раскрытий чужих уязвимостей.
Нашли подозрительное — разберём вашу ситуацию
Если что-то из 47 пунктов не сходится, видели странную активность в логах, не уверены — взломали или нет, или просто хотите второе мнение по конкретной находке — пишите мне в Telegram. Я не выкладываю чужие уязвимости публично, NDA по умолчанию. Первичный разбор бесплатный. Если нужен полный аудит — от 15 000 ₽, срок 1-3 дня, отчёт с приоритетами и инструкциями.
Нужен профессиональный аудит 152-ФЗ?
Отчёт за 1–3 дня, устранение нарушений под ключ. От 5 000 ₽.