WEB SAFE AUDIT
Сканировать
v2026.052026-04-20ОБНОВЛЕНО · ПЕРЕВОДЫ: RU · EN

Введение в Web Safe Audit.

Web Safe Audit — это сканер внешнего периметра и безопасности приложений, который пишет отчёт языком, понятным менеджеру, но с доказательствами для аналитика.

Один аудит — это шесть параллельных модулей, объединённый score с прозрачными весами и список findings, готовый к импорту в трекер. Эта документация описывает, как пользоваться сканером, что значит каждый раздел отчёта и как встраивать Web Safe Audit в свой CI/CD.

Быстрый старт

За 90 секунд от регистрации до первого отчёта:

  1. Зарегистрируйтесь через Google или Yandex SSO.
  2. Подтвердите владение доменом — DNS-токеном TXT _webaudit или meta-тегом.
  3. Запустите скан с дефолтным профилем (все 6 модулей).
  4. Получите отчёт в личном кабинете и на e-mail.

Первый запрос через API

# создать скан
curl -X POST https://app.webaudit.tech/api/v1/scans \\
  -H "X-API-Key: $TOKEN" \\
  -H "Content-Type: application/json" \\
  -d '{"target":"acme-corp.io","module":"tls"}'

{ "scan_id": "01HX9Z4K3F..." }

Подтверждение домена

Активные модули (Pentest, в первую очередь) запускаются только по доменам, владельцем которых вы себя доказали. Это разовый ритуал — после подтверждения домен остаётся в списке и для всех будущих сканов уже не требует повторной проверки.

  1. В разделе Домены (`/domains`) добавьте домен и нажмите Запросить TXT.
  2. Скопируйте показанные имя и значение TXT-записи. Имя в каноничной форме — _sec-check.<your-domain>, значение — sec-check-verification=<token>.
  3. Добавьте запись в DNS-зону через панель регистратора. У некоторых регистраторов в поле «Имя» нужно положить только префикс _sec-check (без домена); тип записи — TXT, TTL — Auto (5–10 минут).
  4. Вернитесь в /domains и нажмите Проверить. Если запись ещё не разъехалась по DNS — подождите 1–2 минуты и попробуйте снова. После успеха домен появится в списке подтверждённых.

Если регистратор не даёт добавить TXT (например, у вас домен корпоративной зоны) — есть альтернатива через файл /.well-known/sec-check-verification.txt на корне домена. Внутри должен лежать тот же токен, что показан в UI.

Запуск первого скана

После подтверждения домена откройте Сканы → Запуск. Шесть аудит-модулей запускаются параллельно одной кнопкой; pentest — отдельным запуском с собственным таймаутом.

  • Цель — домен или URL. Можно с http(s):// и нестандартным портом для headers/tech (TLS-модуль работает только по 443).
  • Профиль — Audit (6 модулей: TLS / Headers / DNS / Surface / Tech / Cookies) или Pentest (fast / full). Аудит запускается без подтверждения, pentest — только по подтверждённому домену.
  • Модули — таблица с весами и ETA. Можно снять любой модуль галочкой, если он не нужен (он будет просто исключён из взвешенного среднего).

Результат появляется во вкладке Сканы → История как только модули отработают. Финальный отчёт со score'ом и рекомендациями собирается автоматически на Отчёты — оттуда же скачивается PDF и приходит дубль на email, если он указан в профиле.

Скоринг с весами

Итоговая оценка считается в две стадии. Сначала каждый модуль даёт собственный 0–100 score (по правилам своего модуля), они складываются по весам — сумма равна 100, если все модули запущены. Затем поверх взвешенного среднего применяется severity-ceiling: один critical-finding перекрывает любые "чистые" модули и опускает итоговую оценку до жёсткого потолка.

Стадия 1 — взвешенное среднее по запущенным модулям:

0.40Pentest
0.19Surface
0.14Tech
0.09TLS
0.07Headers
0.06DNS
0.05Cookies
base_score = Σ(wᵢ · moduleᵢ) / Σwᵢ
             Σwᵢ = 1.00 when every module ran

Если модуль не запускался (например, при per-module scan), его вес исключается из знаменателя — отсутствующий модуль не штрафует и не лечит итоговый score. Per-module формулы: TLS = верификация цепочки 70 + сертификат не близко к expiry 30. Headers = сумма по 5 заголовкам (HSTS 25 / CSP 25 / X-Frame-Options 20 / X-Content-Type-Options 15 / Referrer-Policy 15). DNS = SPF 35 + DMARC 35 + NS 15 + MX 15. Surface = robots 35 + security.txt 35 + sitemap 20 + sitemap-entries 10. Tech — информационный: 100 если есть найденные технологии, иначе 50/30. Cookies — severity-driven: чистые куки 100, low-only 75, medium 50, high 25, high+critical 10. Pentest — severity-aware risk score (критика и эксплозы дают сильное падение).

Стадия 2 — severity-ceiling + штраф за каждую находку:

# потолок по самой тяжёлой находке
if critical >= 1   →  ceiling = 40
elif high >= 3      →  ceiling = 55
elif high >= 1      →  ceiling = 65
elif medium >= 5    →  ceiling = 70
elif medium >= 1    →  ceiling = 80
else                →  ceiling = 100

Затем считается штраф penalty = crit·8 + high·4 + med·2 + low·1 + exposure_signals (всего не больше 45). Итог = max(0, min(100, min(base_score − penalty, ceiling))). Логика: чистый weighted-average не должен "скрывать" критическую находку — один открытый `/.env` опускает итог максимум до 40, даже если TLS / Headers / DNS у клиента идеальны.

Score — не самооценка. Это плотный сигнал для менеджеров и SLA. Все веса и потолки публично описаны и совпадают с тем, что считает движок в production.

Модули

TLS

TLS-handshake к порту 443 со строгой проверкой цепочки сертификата (`CERT_REQUIRED`) и совпадения hostname. Из ответа извлекаются issuer, subject, SAN, not_before / not_after, дни до истечения (warning < 30 дней, near-expiry < 14, alert < 7), а также договорённая версия протокола (TLS 1.2 / 1.3) и cipher. OCSP, HSTS и certificate transparency сюда не входят — HSTS живёт в модуле Headers.

Headers

Проверка пяти OWASP-рекомендованных HTTP-заголовков на корневом URL: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Каждый отсутствующий заголовок снижает модульный score: HSTS / CSP по 25 баллов, X-Frame-Options 20, остальные по 15. Политики проверяются на наличие, не на качество — "CSP с unsafe-inline" учитывается как присутствующий.

Cookies

Cookie hygiene: HttpOnly / Secure / SameSite / Domain. Флагит session-cookie без HttpOnly (XSS уведёт токен), Secure-флаг на HTTPS-origin, SameSite=None без Secure (молча отбрасывается современными браузерами), отсутствие SameSite (поведение зависит от браузера).

DNS

Записи A/AAAA/CNAME/MX/NS/TXT, проверка SPF и DMARC. Энумерация поддоменов через CT-логи (crt.sh) + DNS-brute-force по wordlist'у ~80 типовых имён (api, admin, staging, vpn, ci, ...). WHOIS: регистратор, дата регистрации, дата истечения с предупреждением за 30 дней до expiry. Related-IP intelligence через PTR + ASN enrichment.

Surface

Метаданные публичной поверхности: HTTP-запросы на /robots.txt, /.well-known/security.txt и /sitemap.xml. Сохраняется preview содержимого, статус-код и (для sitemap) подсчёт количества URL внутри. Энумерация поддоменов — НЕ здесь, она переехала в модуль DNS.

Tech

Fingerprint технологий по содержимому одного HTTP-ответа: парсятся заголовки Server и X-Powered-By, в теле страницы ищутся подписи CDN / реверс-прокси / фреймворков (Cloudflare, Nginx, Apache, Caddy, Express, PHP, Next.js, WordPress, React). Раскрытие версии в Server заголовке отмечается как note. CVE-сопоставление по версии сервера идёт в модуле Pentest.

Pentest

Быстрый профиль (≤ 60 секунд) против allowlist-цели:

  • Port probe — TCP-коннект к 27 портам (21, 22, 25, 53, 80, 110, 143, 161, 443, 445, 465, 587, 993, 995, 3000, 3306, 3389, 5000, 5432, 5601, 6379, 8000, 8080, 8443, 8888, 9200, 27017). Открытые порты возвращаются в отчёт.
  • Exposure paths — HTTP-чек ~30 типовых путей (`/.env`, `/.git/config`, `/admin`, `/swagger.json`, `/phpinfo.php`, ...). 200 OK → critical, 401/403 → medium.
  • CORS probe — отправляется `Origin: https://evil.example` и проверяется зеркальное эхо в `Access-Control-Allow-Origin` + `Access-Control-Allow-Credentials: true`. Зеркальный wildcard с credentials = high.
  • HTTP methods — матрица OPTIONS / TRACE / PUT / DELETE / PATCH. Включённые TRACE или PUT/DELETE на публичном корне отмечаются как medium.
  • Subdomain quick-scan — короткий DNS-brute-force по top-N именам (api / admin / vpn / staging / ...). Резолвящиеся имена попадают в Top-5 рекомендаций.
  • Cookie-on-login — POST на типовые login-эндпоинты (`/login`, `/auth/login`) и проверка возвращённых Set-Cookie: отсутствие `HttpOnly` или `Secure` на session-куке = high.
  • Server-CVE quick-match — сравнение Server-заголовка со списком известных уязвимых версий (Apache 2.4.49 path-traversal, EOL nginx / PHP / OpenSSL / IIS) и эмиссия finding со ссылкой на CVE.

Полный профиль = быстрый + опциональный шаг шаблонных проверок (включается на стороне сервиса) в безопасных категориях — misconfiguration, exposures, takeovers, technologies (без проверки логин-форм с подбором кредов, чтобы не блокировать аккаунты) — плюс опциональный deep-crawl по правилам robots-Allow. Защита от злоупотребления: pentest не запустится без подтверждения владения доменом (раздел «Подтверждение домена» выше) и проверки, что цель резолвится в публичный IP (приватные диапазоны RFC1918 / loopback / link-local отбрасываются).

Все запросы идут с подписанным User-Agent Webaudit-Scanner/4.21.

Аутентификация API

Все запросы к `/api/v1/*` авторизуются заголовком X-API-Key (значение выдаётся в разделе Settings → API-ключи и хранится на стороне клиента). Браузерные запросы из SPA авторизуются session-cookie `wsa_session` + double-submit CSRF `wsa_csrf` — там API key не нужен.

Ключ скоупим по правам: readonly — только GET-эндпоинты (отчёты, скан-история), scans:write — позволяет запускать новые сканы. Превышение rate-limit возвращает `429 Too Many Requests`.

Для входа из браузера дополнительно поддерживается SSO — Yandex и Google. На странице /login при первом входе через SSO аккаунт создаётся автоматически с подтверждённым email. Опционально включается 2FA (TOTP + recovery-коды) в разделе Settings → Безопасность.

API

// получить отчёт
GET /api/v1/scans/01HX9Z4K3F...
X-API-Key: $TOKEN

// 200 OK
{
  "id": "01HX9Z4K3F...",
  "target_raw": "acme-corp.io",
  "target_host": "acme-corp.io",
  "module": "tls",
  "status": "done",
  "score": 87,
  "score_delta": +5,
  "result": { "verify_ok": 1, "days_left": 64 }
}

Webhooks

Настройте URL в Settings → Integrations. Web Safe Audit POST'ит JSON со статусом скана при изменении: queued → running → completed | failed. Подпись — HMAC-SHA256 в заголовке X-Webaudit-Signature.

Rate-limits

Дневные лимиты по тарифу (демо — 10 сканов / 3 отчёта, manager — 50 / 20, pro — 200 / 100, pro+ / admin — без лимита). Поверх — окно частоты 10 запросов / мин на пользователя и на IP. Pentest — отдельный hourly лимит, по умолчанию 3 запуска / час (для manager и pro+ обходится). Превышение возвращает 429 с заголовком Retry-After.

Что мы НЕ делаем

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

  • Эксплуатация уязвимостей. Pentest-модуль делает только пассивные пробы (probe headers, статус-код, ACAO-эхо). Никаких payload'ов, никакого fuzz'а, никакого RCE — даже в `full` профиле.
  • Платёжные данные. Биллинга в приложении нет. Не собираем номера карт, не интегрируем платёжные провайдеры, не храним финансовую информацию.
  • Аналитику и трекеры. Никаких Google Analytics, Yandex Metrika, Mixpanel, Hotjar, Segment. Cookies, которые мы пишем — только strictly-necessary (auth, CSRF, OAuth-state).
  • Хранение паролей в открытом виде. Все пароли через Argon2id с production-уровнем параметров; recovery-коды для 2FA тоже Argon2-хэшируются.
  • Передачу данных третьим лицам. Кроме transactional email (Yandex SMTP) и OAuth-провайдеров на стадии входа — данные не уходят наружу. Никаких отчётов в облака, никаких API ML-моделей.
  • Reklama. Не размещаем рекламу, не продаём анонимизированные данные, не используем cookies для ретаргетинга.

Хранение данных

Что мы храним, как долго и когда удаляем:

  • Отчёты и снапшоты сканов — хранятся до явного удаления пользователем из `/reports`. PDF-копии рендерятся on-demand из снапшота, отдельно не хранятся.
  • Промежуточные логи сканов — хранятся 31 день, после чего автоматически удаляются. В отчёте остаётся итоговый снапшот с findings и evidence — сами по себе сырые логи модулей нужны только для повторного построения отчёта в течение этого окна.
  • Неподтверждённые email-аккаунты — удаляются через 24 часа, если пользователь не перешёл по ссылке подтверждения. Аккаунты, созданные через Яндекс / Google SSO, эту проверку не проходят — у них email уже подтверждён провайдером.
  • Web-сессии и CSRF-токены — по умолчанию живут 3 дня от последней активности (sliding window — каждое действие продлевает). На /login есть чекбокс «Запомнить меня»: с ним сессия становится долгоживущей (≈90 дней без обновления) и подходит для доверенного устройства. На общем устройстве чекбокс лучше не включать. Кнопка «Выйти» и «Завершить все сессии» в Настройках безопасности убивают сессию сразу, независимо от чекбокса.
  • Журнал админских действий — добавляется только на запись (без обновлений и удалений), чтобы аудит-трейл был непрерывным. На текущих объёмах хранится без срока; на больших — добавится ротация ~90 дней.
  • Удаление аккаунта по запросу — нажатие «Удалить аккаунт» в Настройках безопасности немедленно сносит профиль, активные сессии, все привязки, recovery-коды и TOTP-секрет. Сохранённые сканы и отчёты удаляются вместе с аккаунтом.

Не нашли что искали? Telegram-чат · support@webaudit.tech