Если вы выбираете карьеру в этой сфере, начните с кто такой пентестер и сколько он зарабатывает. Для бизнеса полезно также зачем стартапу ранняя безопасность продукта и аудит API.
Запрос «виды пентеста» обычно появляется в двух ситуациях. Либо человек хочет войти в кибербезопасность и понять, чем вообще занимаются этичные хакеры. Либо компания уже выросла до момента, когда «у нас вроде всё ок» перестаёт быть аргументом, и нужно выбрать формат проверки.
Проблема в том, что рынок часто продаёт пентест как магическую услугу: «прогоним сканер — и вы защищены». На практике виды пентеста сильно отличаются по глубине, цене, срокам и пользе. Ниже — понятная карта без воды: какие типы бывают, чем отличаются и какой формат реально нужен продукту.
1. Что такое пентест и чем он не является
Пентест (penetration testing) — это санкционированная проверка безопасности, где команда пытается найти и воспроизвести уязвимости так, как это сделал бы атакующий. Цель не «нажать на все кнопки сканера», а ответить на практические вопросы:
- Можно ли получить доступ к чужим данным?
- Можно ли обойти авторизацию?
- Можно ли эскалировать права?
- Насколько критичен ущерб, если уязвимость эксплуатируется?
- Что чинить в первую очередь?
Пентест — это не:
- автоматический vulnerability scan без ручной проверки;
- сертификат «у вас всё безопасно навсегда»;
- замена нормальной разработке и code review;
- разовый ритуал ради галочки в compliance.
Хороший пентест даёт воспроизводимые находки, понятные риски для бизнеса и план исправлений. Плохой — PDF на 80 страниц с ложными срабатываниями и без контекста.
Ещё один важный нюанс: пентест всегда ограничен временем и правилами. Команда не обязана найти «все уязвимости во вселенной». Она должна максимально эффективно проверить согласованный scope и показать реальные сценарии атаки. Поэтому выбор вида пентеста — это выбор фокуса: что именно вы хотите узнать за выделенный бюджет и срок.
2. Виды пентеста по уровню знаний: black, gray, white box
Это самая популярная классификация. Она отвечает на вопрос: сколько информации команда получает до старта.
Black box — как внешний атакующий
Команда почти ничего не знает о системе: нет исходников, нет схемы сети, часто нет внутренних учёток. Есть только то, что доступно снаружи: сайт, API, формы, публичные эндпоинты.
Плюсы: максимально похоже на реальную внешнюю атаку. Полезно проверить «что видно с интернета».
Минусы: часть глубоких багов можно не успеть найти за срок. Без знания архитектуры сложнее быстро дойти до критичных мест.
Когда нужен: внешний периметр, публичный продукт, проверка «как нас видит случайный хакер».
Gray box — самый практичный формат для бизнеса
Команда получает частичный доступ: тестовые аккаунты разных ролей, документацию API, иногда описание архитектуры. Это уже не «вслепую», но и не полный доступ к коду.
Именно gray box чаще всего даёт лучший баланс цены и пользы. Почему? Потому что атакующий в реальности тоже не всегда полный «чёрный ящик»: у него может быть обычный аккаунт клиента, партнёрский доступ, утёкшая документация или старый токен.
Когда нужен: SaaS, личные кабинеты, мультиролевые системы, API с разграничением прав.
Если говорить совсем прагматично: gray box почти всегда лучше «красивого» black box на бумаге. Вы быстрее доходите до критичных сценариев, меньше тратите бюджет на разведку вслепую и получаете находки, которые команда реально может воспроизвести и закрыть.
White box — максимальная глубина
Есть исходный код, схемы, доступы, иногда участие разработчиков. Это ближе к security code review + пентесту.
Плюсы: выше шанс найти сложные логические баги, небезопасные паттерны, скрытые эндпоинты, проблемы в серверной логике.
Минусы: дороже и требует зрелости команды: нужно уметь безопасно делиться доступом и артефактами.
Когда нужен: fintech, healthcare, критичные ядра платформы, подготовка к серьёзному аудиту инвесторов/клиентов.
3. Внешний и внутренний пентест
External pentest
Проверка снаружи: что торчит в интернет, как защищены публичные сервисы, можно ли через них добраться до чувствительных данных.
Типичные цели: корпоративный сайт, клиентский кабинет, публичное API, VPN, почтовые и админ-панели.
Internal pentest
Проверка изнутри периметра: что произойдёт, если злоумышленник уже попал в сеть — через фишинг, подрядчика, украденный ноутбук или скомпрометированного сотрудника.
Здесь часто ищут: слабые пароли, лишние права, плохую сегментацию, движение по сети, доступ к критичным системам.
Для стартапа с одним веб-продуктом приоритет обычно у внешнего web/API пентеста. Для компании с офисной инфраструктурой и AD — внутренний тоже критичен.
На практике компании часто делают ошибку: заказывают только внешний «скан периметра», хотя основной риск уже внутри продукта — в ролях, API и бизнес-логике. Если ваш главный актив — данные пользователей в SaaS, начинать нужно не с портов, а с авторизации.
4. Виды пентеста по цели атаки
Это вторая важная ось. Даже отличный black box бесполезен, если вы проверяете не ту поверхность, где реально лежат деньги и данные.
1) Пентест веб-приложений
Классика: сайты, кабинеты, админки, формы, сессии, cookies, XSS, CSRF, file upload, IDOR, ошибки авторизации.
Что проверяют чаще всего:
- доступ к чужим объектам по ID;
- XSS в формах, поиске, профилях, комментариях;
- слабые сессии и cookie flags;
- опасные загрузки файлов;
- обход ролей (user → admin).
Если продукт — веб-SaaS, этот тип почти всегда в топе приоритетов. Подробнее про бизнес-риски XSS и BOLA — в статье про OWASP Top 10:2025.
2) Пентест API (REST / GraphQL)
Один из самых недооценённых и самых полезных форматов. Современные продукты живут на API. UI может выглядеть аккуратно, а через прямой запрос к эндпоинту открывается чужой заказ, профиль или платёжная сущность.
Фокус API-пентеста:
- BOLA / IDOR;
- broken authentication;
- mass assignment;
- избыточная выдача данных;
- отсутствие rate limiting;
- ошибки бизнес-логики в массовых операциях.
Именно сюда я чаще всего советую смотреть стартапам и продуктовым командам. UI-баги неприятны. API-баги — это уже деньги, данные и репутация.
Отдельный плюс API-пентеста: он хорошо стыкуется с обучением команды. После аудита можно сразу показать разработчикам и QA, как выглядят типичные BOLA/IDOR, где ломается ownership logic и какие негативные проверки стоит добавить в регресс до релиза.
3) Сетевой пентест
Проверка сетевой инфраструктуры: хосты, сервисы, открытые порты, устаревшее ПО, слабые конфигурации, сегментация.
Полезен компаниям с собственной инфраструктурой, VPN, внутренними серверами. Менее приоритетен чистому SaaS на managed cloud без сложного network footprint.
4) Mobile pentest
iOS/Android приложения: хранение токенов, insecure storage, bypass SSL pinning, API-вызовы из приложения, локальные данные, deep links.
Важно понимать: часто уязвимость не в «кнопке приложения», а в том же backend API, к которому ходит мобильный клиент. Поэтому mobile без API-проверки почти всегда неполон.
5) Cloud pentest
AWS/GCP/Azure и аналоги: IAM, публичные бакеты, ошибочные политики, секреты, metadata services, чрезмерные права сервисов.
Если продукт «на облаке», но доступы разданы хаотично, cloud-конфигурация может быть опаснее самого приложения.
6) Wireless / Wi-Fi
Атаки на беспроводные сети офиса: слабые протоколы, гостевой доступ, rogue AP. Актуально для компаний с физическим офисом и корпоративным Wi-Fi.
7) Social engineering
Фишинг, vishing, pretexting — проверка людей и процессов, а не только кода. Часто именно человек становится точкой входа.
Этот формат чувствительный: нужны чёткие правила, согласование, этические границы и план коммуникации с сотрудниками после теста.
8) Red Team
Не «найти максимум CVE», а проверить способность компании обнаружить и отбить атаку end-to-end. Red team ближе к имитации кампании APT, чем к классическому короткому пентесту.
Это уже зрелый уровень. Для компании без базового AppSec и логирования red team часто рано и дорого. Сначала закройте очевидные дыры в web/API, настройте мониторинг и процесс фиксов — и только потом имитируйте полноценную атакующую кампанию.
5. Как выбрать вид пентеста бизнесу
Не начинайте с вопроса «какой пентест самый крутой». Начинайте с вопроса «где у нас максимальный ущерб при взломе».
Практичная матрица:
- SaaS / личный кабинет / платежи → gray box web + API.
- Публичный сайт без сложной логики → black/gray box web.
- Мобильное приложение → mobile + backend API.
- Корпоративная инфраструктура → external + internal network.
- Сильный compliance / fintech → white box / углублённый AppSec + API.
- Проверка людей и процессов → social engineering (отдельно и аккуратно).
Ещё один важный критерий — готовность чинить. Пентест без выделенного времени на фиксы превращается в красивый отчёт в ящике. Перед запуском договоритесь:
- кто принимает находки;
- какой SLA на критичные баги;
- будет ли retest после исправлений;
- какие среды можно трогать (staging / prod с ограничениями).
6. Что должно быть в хорошем отчёте по пентесту
Не покупайте «магический PDF». Требуйте рабочий артефакт. Нормальный отчёт обычно содержит:
- краткое executive summary для бизнеса;
- список находок с severity;
- шаги воспроизведения;
- доказательства (скрины, запросы, ответы);
- бизнес-влияние понятным языком;
- рекомендации по фиксу;
- приоритеты: что чинить сегодня, что на спринт, что в backlog.
Если в отчёте нет воспроизведения — это почти бесполезно. Если severity завышены у всего подряд — тоже. Хороший пентестер умеет отделять шум от реальной угрозы.
Отдельно просите таблицу приоритетов в понятном виде: Critical / High / Medium / Low + оценка трудозатрат на фикс. Тогда CTO и тимлид могут сразу планировать спринт, а не спорить, «насколько это страшно».
7. Пентест vs vulnerability scan vs bug bounty
Vulnerability scan
Автоматическая проверка известными сигнатурами. Быстро и дёшево. Полезно как регулярный hygiene-check. Не заменяет пентест, потому что плохо ловит бизнес-логику и сложные цепочки.
Penetration test
Ручная + инструментальная работа с целью эксплуатации и оценки реального риска. Глубже, дороже, полезнее для ключевых релизов и due diligence.
Bug bounty
Постоянный поток внешних исследователей за вознаграждение. Отличный слой зрелости, но не стартовая точка. Если у вас нет процесса triage и фиксов, bounty быстро превратится в хаос.
Здоровая последовательность для продукта: базовый AppSec → целевой web/API пентест → регулярные проверки → при зрелости bug bounty.
Что важно понимать новичкам и бизнесу
Для тех, кто учится на пентестера: не пытайтесь сразу «знать все виды». Сначала возьмите один сильный трек — чаще всего web + API. Научитесь находить XSS, IDOR/BOLA, auth bypass, писать отчёт и объяснять риск. Это даёт работу быстрее, чем поверхностное знакомство с десятью доменами.
Для бизнеса: не заказывайте «всё сразу». Закажите то, что бьёт по вашей реальной поверхности атаки. Для большинства digital-компаний это web/API с ролями. Потом уже сеть, cloud, mobile и red team.
И ещё один момент, который редко говорят прямо: самый дорогой пентест — тот, после которого ничего не исправили. Ценность не в названии услуги, а в закрытых рисках. Поэтому перед стартом лучше потратить час на уточнение scope, ролей, окружений и критериев успеха, чем потом получить красивый, но бесполезный отчёт.
8. Частые вопросы
Сколько длится пентест?
Обычно от нескольких дней до нескольких недель. Короткий web/API для небольшого продукта — чаще 5–10 рабочих дней. Большой white box или red team — заметно дольше.
Можно ли делать пентест на проде?
Иногда да, но с жёсткими ограничениями, окном работ и стоп-правилами. Безопаснее начинать со staging, максимально близкого к продакшену.
Как часто нужен пентест?
Минимум — после крупных изменений архитектуры/авторизации и перед серьёзными внешними проверками. Для активного продукта разумный ритм — раз в 6–12 месяцев плюс точечные проверки критичных релизов. Если выкатываете новые роли, платежные сценарии или публичное API — не ждите «года с прошлого пентеста»: лучше сделать короткий целевой аудит именно изменённой поверхности.
Чем пентест отличается от AppSec-аудита?
Пентест больше про эксплуатацию здесь и сейчас. AppSec-аудит шире: процессы, код, CI/CD, модель угроз, практики команды. Часто их комбинируют.
Заключение
Виды пентеста — это не список модных слов для коммерческого предложения. Это разные инструменты под разные риски. Black box показывает внешний взгляд. White box копает глубже. Web и API закрывают самую частую боль digital-продуктов. Сеть, cloud, mobile и social engineering нужны, когда у вас реально есть эти поверхности.
Если выбирать один практичный старт для большинства компаний: gray box пентест веб-приложения и REST API с фокусом на авторизацию, BOLA/IDOR, XSS и бизнес-логику. Дальше — по результатам и зрелости.
Если коротко и жёстко: не покупайте «пентест вообще». Покупайте ответ на конкретный вопрос. Например: «Может ли обычный пользователь через API достать чужие данные?» или «Можно ли из гостевой роли дойти до админских действий?» Когда вопрос ясный, вид пентеста выбирается почти автоматически.
Читайте также: кто такой пентестер и сколько он зарабатывает, почему BOLA и XSS — главные угрозы для бизнеса и зачем стартапу ранний аудит API.
Нужно понять, какой вид пентеста или аудита API подойдёт вашему продукту? Напишите мне в Telegram.
Подписывайтесь на канал, а для разбора вашего кейса пишите в @faroeman.
