Аудит безопасности сайта: что проверяют и что получает заказчик

Разбираем по пунктам, из чего состоит технический аудит — от контроля доступа до требований 152-ФЗ

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

Что такое аудит безопасности сайта и чем он отличается от смежных проверок

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

• Технический SEO-аудит проверяет индексацию, скорость, дубли страниц и мобильную адаптивность — безопасность там присутствует лишь как один из второстепенных пунктов чек-листа .
• Пентест (тестирование на проникновение) — это конкретная методика с письменным разрешением заказчика, в рамках которой специалист имитирует действия атакующего, чтобы подтвердить эксплуатируемость уязвимостей на практике. Аудит безопасности шире: он включает не только попытки взлома, но и проверку конфигураций, прав доступа, резервного копирования, журналов и юридического соответствия — то, что пентест как таковой не покрывает.

Разница принципиальна и практически: настройка резервных копий, прав доступа или CSP-заголовков — это отдельные технические задачи, а не «полноценный пентест».

На какую методологию опираются проверки

Программу проверки собирают из модели угроз и особенностей проекта. OWASP Web Security Testing Guide задаёт сценарии тестирования, ASVS — проверяемые требования к приложению, а OWASP Top 10 помогает объяснить распространённые классы рисков. Ни один из этих документов сам по себе не является готовым чек-листом для любого сайта. [1][2][3]

Найденные проблемы подтверждают безопасным способом и оценивают с учётом вероятности эксплуатации, влияния на бизнес и доступных защитных мер. CVSS может помочь унифицировать техническую оценку, но итоговый приоритет исправления учитывает контекст конкретного проекта. [4]

Что именно проверяют: по категориям

Контроль доступа и аутентификация

Проверяется, может ли пользователь получить доступ к чужим данным или функциям, изменив параметр запроса (IDOR), обратиться к административным разделам без прав, обойти проверку сессии или использовать чужой токен. Отдельно тестируют логику восстановления пароля, двухфакторную аутентификацию, защиту от подбора логина и пароля (брутфорса) и корректность настройки CSRF-токенов и cookie-атрибута SameSite .

Инъекции и обработка пользовательского ввода

Классический блок: SQL- и NoSQL-инъекции, инъекции команд операционной системы, шаблонные и LDAP-инъекции. Проверяющий пытается передать в поля форм, параметры URL и заголовки запросов специально сформированные данные, чтобы увидеть, исполняются ли они как часть команды или запроса к базе данных .

Конфигурация сервера и заголовки безопасности

Проверяют настройку Nginx или Apache, версию интерпретатора, TLS и защитные HTTP-заголовки. CSP может снизить последствия части XSS-сценариев, HSTS закрепляет работу по HTTPS, а X-Frame-Options или директива frame-ancestors ограничивает встраивание страницы. Каждый заголовок настраивают под архитектуру сайта и проверяют на тестовом контуре: механическое добавление способно нарушить работу или создать ложное ощущение защиты.

Сторонние зависимости и цепочка поставок

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

Логирование и обнаружение атак

Аудит проверяет, фиксируются ли действия администраторов и подозрительные события, куда они передаются и есть ли работающие оповещения. Без этого атака может развиваться в системе неделями и месяцами, оставаясь незамеченной .

Устойчивость к отказу в обслуживании

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

API и интеграции

Отдельно проверяются авторизация запросов к API, ключи доступа, подпись вебхуков, лимиты на тяжёлые запросы (в том числе для GraphQL) и защита от подмены цены, количества или статуса заказа на стороне клиента вместо сервера.

Специфика популярных CMS

Для сайтов на «1С-Битрикс» отдельно проверяют версии ядра и модулей, права административной панели, штатный сканер, панель безопасности и контроль целостности. Возраст обновления сам по себе не доказывает уязвимость: важны поддержка модуля, известные проблемы, состав кода и совместимость с текущей платформой. Для WordPress аналогично проверяют ядро, плагины, темы, загрузку файлов и административные учётные записи. [5][6][7]

Как проводится аудит: методы и инструменты

В зависимости от объёма информации, предоставленной заказчиком, различают три модели проверки :

• Black box («чёрный ящик») — у проверяющего нет внутренней информации о системе: он видит только домен и работает так же, как реальный внешний злоумышленник.
• Grey box («серый ящик») — заказчик раскрывает часть информации: структуру API, тестовую учётную запись, архитектуру периметра. Это компромисс между реалистичностью атаки и глубиной проверки.
• White box («белый ящик») — проверяющий имеет полный доступ, включая исходный код, что позволяет находить уязвимости, незаметные при внешнем тестировании.

Автоматизированное сканирование выполняют инструменты вроде OWASP ZAP и Burp Suite для веб-приложений, а также специализированные сканеры уязвимостей инфраструктуры . Но автоматика находит далеко не всё: логические ошибки контроля доступа — например, IDOR — плохо поддаются автоматическому обнаружению и требуют ручного тестирования . Поэтому качественный аудит почти всегда сочетает автоматическое сканирование с ручной проверкой конкретных сценариев.

Персональные данные и применимые требования

Статья 19 152-ФЗ требует от оператора правовых, организационных и технических мер защиты персональных данных. Поэтому в аудите сайта проверяют только технически наблюдаемые части: доступы, журналы, формы, хранение, интеграции и возможность обнаружить инцидент. Юридическое соответствие организации целиком по одному сайту установить нельзя. [9]

Приказ ФСТЭК № 21 относится к информационным системам персональных данных. Конкретный состав мер выбирают с учётом уровня защищённости и актуальных угроз; одинаковый набор требований нельзя автоматически переносить на каждую компанию, у которой есть форма обратной связи. [10]

Практические этапы аудита

1. Согласование контура. Фиксируют домены, API, учётные записи, допустимые методы и временные ограничения.
2. Инвентаризация. Уточняют версии CMS, модулей, серверного ПО, внешние зависимости и точки входа.
3. Автоматизированная проверка. Инструменты используют для поиска кандидатов, а не как единственное доказательство.
4. Ручное подтверждение. Специалист воспроизводит риск безопасным способом и исключает ложные срабатывания.
5. Отчёт и приоритеты. Для каждой проблемы указывают затронутый компонент, условие проявления, влияние, подтверждение и способ исправления.
6. Повторная проверка. После изменений подтверждают, что риск устранён и работа сайта не нарушена.

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

Ограничения, типичные ошибки и риски

• Разовый аудит без повторных проверок. Новый код, новая интеграция или обновление CMS могут вернуть уже закрытую уязвимость или создать новую — регулярность важнее глубины одной проверки.
• Слепая вера в автоматический скан. Сканер найдёт устаревшую версию библиотеки, но не найдёт логическую ошибку контроля доступа, которая специфична для бизнес-процесса конкретного сайта .
• WAF как замена исправлению кода. Веб-файрвол снижает риск эксплуатации уязвимости, но не устраняет её первопричину — при смене правил или появлении обходного пути риск возвращается.
• Исправление симптома, а не архитектурной причины. Часть уязвимостей — например, категория Insecure Design — невозможно закрыть патчем: требуется пересмотр логики работы приложения .
• Работа над устранением без подтверждения. Отчёт о том, что «уязвимость исправлена», без независимой повторной проверки — это предположение, а не факт.
• Отсутствие плана на случай инцидента. Даже качественная защита не исключает вероятность инцидента полностью — важно заранее понимать, как сайт будет реагировать: есть ли актуальная резервная копия, кто получает оповещение, какие действия предпринимаются в первые часы.

Как выбрать формат проверки

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

• Сайт-визитка без форм и личного кабинета — обычно достаточно базовой проверки конфигурации, заголовков безопасности и актуальности CMS.
• Сайт с формами и персональными данными — нужен отдельный блок по 152-ФЗ: согласия, места хранения данных, готовность к запросам на удаление.
• Интернет-магазин с оплатой — приоритет на защиту логики цены и заказа, личного кабинета от credential stuffing и, если применимо, требования PCI DSS к странице оплаты.
• Сайт с API и внешними интеграциями — отдельная проверка авторизации API, ключей, вебхуков и партнёрских интеграций.
• Инфраструктура с высокими требованиями к доступности — защита от DDoS, отказоустойчивость, план аварийного восстановления с измеримыми RTO и RPO.

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

Как может помочь «Пятый фактор»

Команда «Пятого фактора» занимается точечными техническими задачами для сайтов с заранее известной стоимостью и сроком, включая направление безопасности и эксплуатации. В каталоге услуг есть как узкие задачи — настройка CSP и защитных заголовков, укрепление доступа в административную часть, настройка WAF, защита от DDoS, поиск персональных данных в Метрике и логах, — так и комплексные форматы: аудит безопасности сайта и API по методологии OWASP, технический аудит по требованиям 152-ФЗ и комплексный аудит безопасности сайта, сервера и инфраструктуры . Если пока не очевидно, какой формат нужен именно вашему сайту, имеет смысл начать с обсуждения конкретной ситуации — набор проверок и приоритеты у сайта-визитки, интернет-магазина и сервиса с личным кабинетом будут заметно различаться.

Вывод

Аудит безопасности сайта — это не единая проверка, а комбинация методик: анализ контроля доступа и аутентификации, поиск инъекций, проверка конфигурации сервера и шифрования, оценка сторонних зависимостей, аудит логирования и, для большинства российских сайтов, отдельный технический блок по 152-ФЗ. Глубина и формат проверки должны соответствовать тому, что сайт делает и какие данные обрабатывает: не каждому сайту нужен полноценный пентест, но у каждого сайта, который собирает данные пользователей или принимает оплату, должен быть понятный ответ на вопрос, когда в последний раз проверялась его защита.

Источники

[1] OWASP Web Security Testing Guide — https://owasp.org/www-project-web-security-testing-guide/

[2] OWASP Application Security Verification Standard 5.0 — https://owasp.org/www-project-application-security-verification-standard/

[3] OWASP Top 10: 2025 — https://owasp.org/Top10/2025/

[4] FIRST — CVSS v4.0 Specification — https://www.first.org/cvss/v4.0/specification-document

[5] 1С-Битрикс — Сканер безопасности — https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=35&LESSON_ID=6639&LESSON_PATH=3906.4829.4547.5294.6639

[6] 1С-Битрикс — Панель безопасности — https://dev.1c-bitrix.ru/user_help/settings/security/security_panel.php

[7] 1С-Битрикс — Контроль целостности файлов — https://dev.1c-bitrix.ru/user_help/settings/security/security_file_verifier.php

[8] OWASP Multifactor Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html

[9] Официальное опубликование правовых актов — 152-ФЗ, статья 19 — https://ips.pravo.gov.ru/api/ips/legislation/document?baseid=None&hash=98490812b3409e2a8d78a11ca9010f434ea3d9250a11dbbdb78690cd5551bdd6

[10] ФСТЭК России — приказ № 21 от 18.02.2013 — https://fstec.ru/dokumenty/vse-dokumenty/prikazy/prikaz-fstek-rossii-ot-18-fevralya-2013-g-n-21