Сайт та кабінет користувача — найпомітніша частина бізнесу в інтернеті, а отже й найчастіша мішень. Пентест сайту перевіряє не інфраструктуру, а сам продукт: його логіку, форми, вхід, обробку введеного. Розберемо, що саме тестують, які дефекти спливають найчастіше і чим мобільна перевірка відрізняється від вебової. Загальний устрій процесу — в оглядовій статті Пентест: що це і як проходить, а мережевий периметр — у матеріалі про перевірку мережі.
Як цю послугу шукають: формулювання і що за ними стоїть
Одна робота розсипається в запитах на десяток варіантів — і кожен натякає на різні очікування:
- «пентест сайту» — мають на увазі публічний ресурс;
- «пентест веб-застосунків» — ідеться про кабінет, панель керування, API;
- «пентест мобільних застосунків» — окремий фах із власним інструментарієм;
- «пентест онлайн» — очікують швидку автоматичну перевірку просто з браузера;
- «pentest-аудит» — калька, під якою іноді продають звичайне сканування;
- «пентест послуги» — шукають уже виконавця, а не пояснення.
Два формулювання з цього списку варті окремої обережності. Пентест онлайн зазвичай означає автоматичний сканер: корисно, дешево, але це інша послуга. Pentest-аудит звучить солідно, проте лишається порожнім — питайте, чи буде ручний аналіз та докази знахідок. Різницю розібрано у статті аналіз вразливостей проти пентесту.
Що перевіряють
- контроль доступу — чи дістанеться користувач до чужих даних або функцій адміністратора;
- вхід та сесії — надійність автентифікації, захист від перебору, керування сесіями;
- обробку введеного — чи можна протягнути шкідливий код через форми (ін'єкції, XSS);
- конфігурацію — небезпечні налаштування за замовчуванням, зайві служби, витік технічних подробиць у повідомленнях про помилки;
- бізнес-логіку — чи вдасться обійти правила;
- роботу з файлами — завантаження, зберігання, доступ;
- залежності — вразливі сторонні бібліотеки й компоненти.
OWASP Top 10:2025 — орієнтир, а не контрольний список
Галузевий орієнтир для вебпродуктів — OWASP Top 10. Чинна редакція — 2025 року:
| № | Категорія | Що змінилося |
|---|---|---|
| A01 | Порушений контроль доступу | лишається ризиком №1; сюди влилася SSRF, а також явно віднесено BOLA і BFLA |
| A02 | Помилки конфігурації | піднялися з 5-го місця на 2-ге |
| A03 | Збої ланцюга постачання ПЗ | нова категорія — розширення колишніх «вразливих компонентів» |
| A04 | Проблеми криптографії | слабке, застаріле або відсутнє шифрування |
| A05 | Ін'єкції | сюди входить і XSS |
| A06 | Небезпечний задум | хиби архітектури, а не коду |
| A07 | Збої автентифікації | назву скорочено |
| A08 | Порушення цілісності ПЗ і даних | непідписані оновлення, неперевірені артефакти збірки |
| A09 | Збої журналювання і сповіщень | акцент змістився на сповіщення |
| A10 | Неправильна обробка виняткових ситуацій | нова категорія |
Важлива деталь, яку пропускають майже всі: Top 10 — документ поінформованості, а не методика перевірки. Сам OWASP для тестування пропонує інші свої напрацювання — ASVS (перелік перевірюваних вимог) та WSTG (посібник із тестування). Тож фраза «перевіряємо за Top 10» у пропозиції — радше маркетинг: за десятьма назвами категорій перевіряти нічого. Докладніше про сімейство документів — у матеріалі NIST, NICE і OWASP.
Перелік оновлюють раз на три-чотири роки, тож матеріали з редакцією 2021 року вже застаріли.
Ще одна деталь: A06 «Небезпечний задум» узагалі не перевіряється тестом. Хибу архітектури видно на схемі, а не у відповіді сервера.
Бізнес-логіка: те, чого сканер не бачить
Саме тут проходить межа між автоматом і фахівцем. Сканер знає сигнатури, але не знає, як має працювати ваш продукт. Класичні знахідки ручного аналізу:
- ціна товару приходить із браузера — і її можна змінити перед оплатою;
- крок підтвердження оплати вдається пропустити, перейшовши одразу до сторінки успіху;
- знижку або промокод можна застосувати повторно;
- у посиланні на документ змінюється номер — і відкривається чужий рахунок.
Жоден сканер не позначить це помилкою: сервер відповідає коректно, просто робить не те, чого від нього чекали. А б'ють такі хиби напряму по касі: кожен обхід оплати — це втрачений чек. Тому ціна ручної роботи й формує вартість послуги — про це в матеріалі з чого складається ціна.
API: поверхня без інтерфейсу
Кабінет користувача — це вершина айсберга, а працює під ним API. Особливості перевірки:
- сканер не бачить того, чого не знає. Без специфікації (OpenAPI/Swagger) частина точок входу просто не потрапить у покриття — тож специфікацію треба віддати команді;
- авторизація на рівні об'єкта. BOLA — доступ до чужого запису через підміну ідентифікатора; BFLA — виклик адміністративної функції звичайним користувачем. У редакції 2025 обидва явно віднесено до A01;
- обмеження частоти запитів. Форма входу може бути захищена, а той самий метод в API — ні;
- окремий орієнтир. OWASP веде API Security Top 10 окремо від вебового переліку.
Практичний наслідок простий: якщо в межах є кабінет, у межах має бути й API під ним.
Частину цих ризиків на рівні трафіку прикриває WAF, але фільтр не виправляє код і найслабший саме там, де ризик №1, — у контролі доступу.
Мобільна перевірка: що додається
Тест мобільного продукту включає все вебове (бо сервер той самий), плюс те, чого у браузері немає:
- що застосунок лишає на самому пристрої — токени, ключі, кеш, журнали;
- чи витримає з'єднання підміну сертифіката (закріплення сертифіката);
- як поводиться на пристрої з розблокованим адміністраторським доступом;
- чи «зашиті» секрети просто в код — його можна розібрати та прочитати;
- окремий орієнтир — OWASP Mobile Top 10.
Головна пастка — вважати, ніби захищена серверна частина автоматично прикриває й пристрій користувача.
Що підготувати перед роботою
- Облікові записи всіх ролей — і мінімум по два в кожній. Без другого користувача неможливо перевірити головний ризик: доступ до чужих даних.
- Середовище-копія без бойових даних. Структура та сама, вміст — синтетичний.
- Специфікація API — інакше частина поверхні лишиться неперевіреною.
- Білий список для фільтра й мережі доставлення. Інакше адреси команди заблокують на п'ятій хвилині.
- Попереджений платіжний провайдер — інакше тестові оплати обернуться розслідуванням шахрайства.
- Узгоджене вікно робіт. Перевірка форм зворотного зв'язку здатна залити менеджерів сотнями листів — краще домовитися заздалегідь.
Типова помилка меж
Перевіряють бойовий ресурс, а адміністративну панель на піддомені до переліку не вносять — «вона ж внутрішня». Тим часом бібліотеки там ті самі, а автентифікація часто слабша. Нападник почне саме з неї. Те саме стосується забутих версій продукту, доступних за адресами на кшталт old або staging: вміст там застарілий, а дірки — цілком свіжі. Коли перевірка взагалі виправдана, розібрано у статті коли вона потрібна, а коли зарано.
Потрібна перевірка вебпродукту чи мобільного застосунку? Фахівці узгодять межі, проведуть ручний аналіз і нададуть звіт із пріоритетами — отримати консультацію.