Пентест

Як перевірити безпеку сайту та API: що входить у тест вебзастосунку?

Що входить у тест безпеки сайту й API: ризики OWASP простими словами, що підготувати, що не входить, який звіт отримаєте. Таблиця й чекліст.

Автор: Vlad Kraevsky · 24 жовтня 2026 · 7 хв читання

API: Як перевірити безпеку сайту та API. Ризики OWASP; Тестові акаунти; Межі перевірки; Звіт

Зміст статті

Коротко
Що перевіряють: ризики OWASP простими словами
Що потрібно від вас
Що не входить у тест
Що ви отримаєте
Як обрати виконавця
Чекліст перед тестом сайту й API
FAQ
Посилання

Безпеку сайту й API перевіряють тестом на проникнення вебзастосунку: фахівець з письмового дозволу вручну пробує зробити те, що зробили б зловмисники, під кожною роллю користувача і за списками ризиків OWASP Top 10 та OWASP API Security Top 10. На виході ви отримуєте звіт із відтвореними знахідками, впливом на бізнес і порядком виправлень, а після виправлень повторну перевірку; в Україні такий пентест сайту й API робить, зокрема, Veiltrack.

Тест вебзастосунку означає перевірку сайту, кабінету клієнта й API людиною, яка думає як зловмисник, але працює лише в погоджених межах. API (спосіб, яким застосунки обмінюються даними) часто важливіший за сам сайт: через нього працюють мобільний застосунок, інтеграції з партнерами й платежі. Нижче пояснюю найважливіші ризики простими словами, що потрібно від вас, що не входить у тест і що ви отримаєте в кінці.

Коротко

Головні ризики описані у двох списках OWASP (міжнародної некомерційної спільноти з безпеки застосунків): для вебзастосунків і окремо для API. ^[1] ^[2]
Найчастіша і найдорожча проблема проста: користувач бачить або змінює чужі дані. Знайти її може лише людина з кількома тестовими акаунтами.
Від вас потрібні межі перевірки, по два тестові акаунти на кожну роль, документація API і письмовий дозвіл.
Тест не перевіряє сторонні сервіси без дозволу їхнього власника і не дає гарантії, що помилок більше немає.
Корисний звіт пояснює вплив на бізнес, показує, як відтворити кожну знахідку, і чесно каже, що не перевіряли.

Що перевіряють: ризики OWASP простими словами

OWASP Top 10 (редакція 2021 року) описує десять найважливіших ризиків для вебзастосунків, а OWASP API Security Top 10 (2023) робить те саме для API. ^[1] ^[2] У 2025 році вийшла нова редакція вебсписку, і порушення контролю доступу там знову на першому місці. ^[3] Для власника бізнесу корисніше не заучувати номери, а розуміти, що може статися. Ось вісім ризиків, які найчастіше мають значення для сайту з кабінетом клієнта та API.

Ризик	Приклад	Як перевіряють
Чужі дані за номером (A01, API1)	Покупець змінює номер замовлення в адресі чи запиті й бачить чуже замовлення з телефоном і адресою	Під одним тестовим акаунтом пробують відкрити замовлення, документи й профілі іншого
Дії не за роллю (A01, API5)	Менеджер напряму через API викликає функцію адміністратора «видалити користувача», хоча кнопки в нього немає	Повторюють запити адміністратора під акаунтом з меншими правами
Зайві поля в запиті й відповіді (API3)	API віддає повну картку клієнта з паспортними даними, хоча на екрані лише ім'я; або користувач дописує собі роль адміністратора	Читають повні відповіді API, додають і змінюють поля в запитах
Слабкий вхід і сесії (A07, API2)	Пароль можна перебирати без обмежень, посилання для скидання пароля діє тиждень, вихід не завершує сесію	Перевіряють ліміти спроб, скидання пароля, другий фактор входу, тривалість сесії
Підстановка команд (A03)	У поле пошуку вводять шматок запиту до бази даних, і сайт віддає список усіх клієнтів	Підставляють спецсимволи й команди в усі поля та параметри, вручну й інструментами
Помилки логіки бізнесу (A04, API6)	Один промокод застосовують десять разів, бот скуповує всі квитки за хвилину	Пробують кроки не в тому порядку, повтори, від'ємні кількості, масові запити
Небезпечні налаштування (A05, API8)	Відкрита панель адміністратора, сторінка помилки показує шматок коду, забута тестова копія API	Перевіряють службові адреси, сторінки помилок, заголовки, налаштування HTTPS
Застарілі компоненти й забуті версії API (A06, API9)	Старий плагін WordPress з відомою вразливістю; стара версія API працює без нових перевірок	Звіряють версії з базами відомих вразливостей, шукають старі й незадокументовані адреси API

Більшість рядків цієї таблиці автоматичний сканер не знайде: для нього сторінка з чужим замовленням виглядає як звичайна робоча сторінка. Чим сканування відрізняється від ручної перевірки, пояснюю в статті пентест чи сканування вразливостей. Методику ручної перевірки OWASP описує у своєму посібнику з тестування. ^[4]

Що потрібно від вас

Тест іде швидше і знаходить більше, коли все це готово до старту:

Межі перевірки. Список доменів, адрес API і середовищ: робоча система чи staging (копія системи для тестів).
Тестові акаунти. По два на кожну роль: клієнт, менеджер, адміністратор, партнер. Без другого акаунта тієї самої ролі не перевірити доступ до чужих даних.
Документація API. Опис OpenAPI або Swagger (перелік усіх запитів у стандартному форматі) чи колекція Postman. Без неї частина API лишається непоміченою.
Тестові дані. Тестові картки платіжного провайдера, записи без реальних персональних даних.
Другий фактор входу. Як тестувальник отримуватиме коди для тестових акаунтів.
Письмовий дозвіл і правила роботи. Дати, години, заборонені дії і контакт, який може зупинити тест.
Рішення щодо WAF (фільтра вебзапитів). Чи додати адреси тестувальників у виняток, щоб перевіряти сайт, а не фільтр.

Повний список підготовки з таблицею відповідальних є в статті як підготуватися до пентесту.

Що не входить у тест

Межі важливі не менше, ніж обсяг. Зазвичай поза тестом лишаються:

атаки на відмову в обслуговуванні (DoS, перевантаження сервісу запитами);
сторонні сервіси: платіжний провайдер, хмарна CRM, поштовий сервіс, їх не можна тестувати без дозволу власника;
фішинг співробітників і фізичний доступ до офісу, для цього є окремі формати;
мобільний застосунок, внутрішня мережа й хмарні налаштування, якщо їх не внесли в обсяг окремо;
повний аудит вихідного коду, якщо його не погодили.

Тест показує стан системи на дату перевірки в погоджених межах. Він не гарантує, що помилок більше немає, і не замінює безпечну розробку. NCSC радить сприймати пентест як перевірку того, чи працюють ваші процеси пошуку й закриття вразливостей, а не як головний спосіб їх знаходити. ^[5]

Що ви отримаєте

Короткий підсумок для керівництва: що знайдено, чим це загрожує бізнесу, що робити першим.
Кожну знахідку окремо: де вона, як її відтворити крок за кроком, доказ, вплив, рівень серйозності і як виправити. Рівень часто оцінюють за CVSS (шкалою серйозності від 0 до 10). ^[6]
Перелік перевіреного і неперевіреного, щоб ніхто не вважав безпечним те, чого не тестували.
Повідомлення про критичне одразу, без очікування звіту.
Ретест (повторну перевірку після виправлень), якщо він входить у погоджений обсяг. Узгодьте це до старту.

NIST описує ці етапи, від планування до звіту, у своєму посібнику з технічного тестування безпеки. ^[7]

Як обрати виконавця

Поставте три запитання. Скільки часу працює людина руками і що саме вона перевіряє під кожною роллю? Чи можна побачити знеособлений приклад звіту? Чи входить ретест у ціну? Якщо у відповідь чуєте лише назву сканера, це не тест вебзастосунку. Більше запитань і тривожних знаків зібрано в статті як обрати компанію для пентесту.

Чекліст перед тестом сайту й API

Завантажити чекліст підготовки (PDF)PDF · A4

FAQ

Порадьте компанію в Україні, яка перевірить безпеку сайту і API?

Шукайте виконавця, який перевіряє вручну під кожною роллю, працює лише з письмовим дозволом, показує приклад звіту і робить ретест. Я проводжу саме такі перевірки, деталі на сторінці пентесту.

Скільки триває тест сайту й API?

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

Чи можна обійтися автоматичним сканером?

Ні, якщо у вас є кабінет клієнта чи API. Сканер знаходить застарілі версії й небезпечні налаштування, але не бачить, що один клієнт відкриває дані іншого. Регулярне сканування корисне між тестами, а не замість них.

Чи безпечно тестувати робочий сайт?

Так, якщо правила це враховують: обережні перевірки, погоджені години, свіжа резервна копія і людина на зв'язку. Агресивніші сценарії краще залишити для staging.

Що таке OWASP Top 10 і чи він досі актуальний?

Це список найважливіших ризиків для вебзастосунків від некомерційної спільноти OWASP. Редакція 2021 року досі широко використовується, у 2025 році вийшла оновлена, а для API є окремий список 2023 року. ^[1] ^[2] ^[3]

Посилання

OWASP Top 10:2021 top10.owasp.org
OWASP Top 10 API Security Risks 2023 api-security.owasp.org
OWASP Top 10:2025 top10.owasp.org
OWASP Web Security Testing Guide: Introduction wstg.owasp.org
NCSC: Penetration testing ncsc.gov.uk
FIRST: Common Vulnerability Scoring System first.org
NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov