Тестування безпеки у 2026 році: що перевіряти, як почати й які інструменти обрати

Функціональний тест перевіряє, що застосунок робить те, що має. Тест безпеки перевіряє протилежне: що він не робить того, чого не повинен — не показує чужі дані, не пускає без пароля, не виконує код, вставлений у поле коментаря, не зберігає паролі відкритим текстом. Одна така помилка може коштувати компанії витоку бази клієнтів, штрафів і репутації.

Тестування безпеки — окрема спеціальність, але базові перевірки під силу кожному тестувальнику, а багато інструментів працюють автоматично в CI. У статті розповідаємо, з чого почати, що перевіряти й які інструменти обрати — від безкоштовних сканерів до легальних тренажерів.

Короткий вибір

Види тестування безпеки

• SAST (статичний аналіз) — інструмент читає вихідний код і шукає небезпечні конструкції: SQL-запити, зібрані зі змінних, вимкнену перевірку сертифіката, слабку криптографію. Працює ще до запуску застосунку, зручно в CI й IDE.
• DAST (динамічний аналіз) — сканер атакує запущений застосунок ззовні, як зловмисник: надсилає шкідливі значення в поля й параметри й аналізує відповіді. Не потребує доступу до коду.
• SCA (аналіз складу ПЗ) — перевірка сторонніх бібліотек на відомі вразливості. Більша частина коду сучасного застосунку — залежності, і вразливість у популярній бібліотеці стає вразливістю у вашому продукті.
• Пошук секретів — ключі API, паролі й токени, випадково закомічені в репозиторій.
• Ручне тестування безпеки — тестувальник працює з перехоплювальним проксі й перевіряє логіку: права доступу, бізнес-сценарії, обхід обмежень. Сканери таких помилок майже не знаходять.
• Тестування на проникнення (пентест) — комплексна атака на систему професіоналами за погодженими правилами з підсумковим звітом.
• Bug bounty — компанія дозволяє зовнішнім дослідникам шукати вразливості й платить за знахідки через платформи HackerOne чи Bugcrowd.

Добра стратегія поєднує все: SAST, SCA й пошук секретів — автоматично на кожен коміт, DAST — на тестовому середовищі, ручні перевірки — для критичних функцій, пентест — перед великими релізами.

OWASP Top 10: що шукати

OWASP Top 10 — список найпоширеніших і найнебезпечніших категорій вразливостей вебзастосунків, на який орієнтуються і тестувальники, і розробники. Чинна версія — OWASP Top 10:2025. Її категорії в практичному викладі:

1. Порушення контролю доступу. Користувач бачить або змінює чужі дані, змінивши id в адресі (/orders/1001 → /orders/1002), відкриває адмінську сторінку за прямим посиланням, звичайний користувач виконує дію адміністратора через API. Сюди ж тепер належить SSRF — коли сервер можна змусити звернутися до внутрішньої адреси.

2. Неправильна конфігурація. Увімкнений режим налагодження, стандартні паролі, відкриті службові сторінки, відсутні заголовки безпеки.

3. Збої в ланцюжку постачання ПЗ. Вразливі, застарілі чи навіть шкідливі бібліотеки, скомпрометовані інструменти збирання й CI.

4. Помилки криптографії. Паролі зберігаються без надійного хешування, дані передаються без HTTPS, застарілі протоколи TLS.

5. Ін’єкції. SQL-ін’єкції, XSS (виконання JavaScript, вставленого в поле), ін’єкції команд — усюди, де дані користувача потрапляють у запит чи сторінку без обробки.

6. Небезпечний дизайн. Немає обмеження спроб входу, код підтвердження з 4 цифр без ліміту, знижку можна застосувати багато разів.

7. Помилки автентифікації. Слабкі вимоги до пароля, сесія не завершується після виходу, токен скидання пароля можна вгадати чи використати повторно.

8. Порушення цілісності ПЗ і даних. Оновлення чи плагіни без перевірки підпису, небезпечна десеріалізація.

9. Недостатнє логування й сповіщення. Атаку ніхто не помічає, бо підозрілі дії не записуються або ніхто не отримує сигналу.

10. Неправильна обробка виняткових ситуацій. Застосунок під час помилки показує стектрейс і внутрішні дані або, навпаки, «відкривається»: пропускає перевірку, якщо щось пішло не так.

Для API є окремий список — OWASP API Security Top 10, а для мобільних — OWASP Mobile Top 10.

Чек-лист для тестувальника

Ці перевірки можна робити без глибоких знань безпеки:

Автентифікація й сесії

• вхід з неправильним паролем багато разів поспіль — чи є обмеження або капча;
• повідомлення про помилку не підказує, чи існує такий email;
• після виходу кнопка «Назад» і старий токен не дають доступу;
• посилання для скидання пароля одноразове й має обмежений термін дії.

Права доступу

• зайдіть під двома користувачами й спробуйте відкрити чи змінити дані одного з-під іншого, підмінивши id в адресі чи запиті;
• звичайний користувач не може відкрити адмінські сторінки й викликати адмінські API;
• зайві поля в запиті (наприклад, "role": "admin" чи "price": 0) ігноруються сервером.

Введення даних

• у текстові поля спробуйте <script>alert(1)</script>, "><img src=x onerror=alert(1)> і лапки ' — текст має відображатися як текст, без виконання коду й без помилок бази даних;
• завантаження файлів: чи можна завантажити .php, .html чи файл із подвійним розширенням, чи перевіряється розмір;
• зручно підставляти такі значення розширенням BugMagnet.

Дані й конфігурація

• усе працює лише через HTTPS, без змішаного контенту;
• у відповідях API немає зайвих даних (паролів, хешів, внутрішніх полів), у помилках — стектрейсів;
• заголовки безпеки перевірте в HTTP Observatory чи Security Headers, налаштування HTTPS — у SSL Labs;
• cookies сесії мають атрибути Secure, HttpOnly і SameSite.

Кожну знайдену вразливість оформлюйте як звичайний баг, але з позначкою безпеки й обмеженим доступом у трекері, наприклад у Jira. Не публікуйте деталі у відкритих каналах до виправлення.

Перехоплювальні проксі: головний інструмент ручного тестування

Проксі стає між браузером і сервером: ви бачите кожен запит і можете змінити його перед відправкою — підмінити id, роль, ціну, обійти перевірку на фронтенді.

• Burp Suite від PortSwigger — галузевий стандарт. Безкоштовна Community Edition містить проксі, Repeater для повтору запитів і Decoder; платна Professional додає автоматичний сканер.
• ZAP — безкоштовний відкритий аналог з автоматичним сканером, зручний і для ручної роботи, і для запуску в CI.
• Caido — сучасна легша альтернатива з фільтрами HTTPQL і безкоштовним тарифом.
• mitmproxy — консольний проксі зі скриптами на Python.

Для аналізу мережевого рівня є Wireshark: він покаже, чи не передаються дані відкритим текстом.

Автоматичні сканери

Вебзастосунки й API (DAST):

• ZAP — автоматичне сканування й «базовий» пасивний режим, безпечний навіть для тестового середовища з даними;
• Nuclei — тисячі шаблонів перевірок відомих вразливостей і помилок конфігурації;
• Nikto — класичний сканер вебсерверів;
• sqlmap — автоматичне підтвердження SQL-ін’єкцій;
• ffuf — пошук прихованих сторінок, резервних копій і параметрів;
• комерційні платформи Invicti і Detectify — для регулярного сканування багатьох сайтів.

Інфраструктура:

• Nmap — які порти відкриті й які сервіси на них працюють;
• OpenVAS (безкоштовно), Nessus (є безкоштовна Essentials) і Intruder — сканування серверів на відомі вразливості й відсутні оновлення;
• Kali Linux — дистрибутив, де більшість цих інструментів уже встановлено; Metasploit — платформа для перевірки, чи вразливість справді можна використати (для досвідчених пентестерів).

Сканер — помічник, а не суддя: він дає хибні спрацювання й не бачить логічних помилок. Кожну знахідку перевіряйте вручну.

Безпека в коді й CI (DevSecOps)

Найдешевше виправляти вразливість до того, як код потрапив у продакшн:

• SAST: Semgrep, SonarQube (є безкоштовна Community Build), GitHub Advanced Security, Checkmarx One, Veracode, Aikido Security;
• залежності: Snyk, OWASP Dependency-Check, Socket (виявляє шкідливі пакети);
• контейнери й інфраструктура як код: Trivy;
• секрети: Gitleaks як pre-commit hook, TruffleHog (перевіряє, чи ключ досі дійсний), GitGuardian.

Запускайте ці перевірки в GitHub Actions чи Jenkins на кожен pull request, а базове сканування ZAP — після розгортання на тестове середовище.

API і мобільні застосунки

API — найчастіша ціль атак: інтерфейс не захищає від запиту, надісланого напряму. Перевіряйте доступ до чужих об’єктів, зайві поля, обмеження частоти запитів і авторизацію кожного методу. Для запитів використовуйте Postman чи Burp Suite, а детальніше про перевірку API — у статті «Тестування API».

Мобільні застосунки аналізує MobSF: небезпечні дозволи, ключі в коді, слабка криптографія. Frida дозволяє дослідити поведінку застосунку під час роботи. Більше — у статтях «Тестування безпеки мобільних застосунків» і «Тестування мобільних застосунків».

АІ-застосунки й чат-боти мають власні вразливості: промпт-ін’єкції, витік системного промпта, надмірні права агентів. Як їх шукати за OWASP Top 10 для LLM — у статті «Тестування АІ-застосунків і LLM».

Де легально потренуватися

• PortSwigger Web Security Academy — найкращий безкоштовний курс із вебвразливостей з інтерактивними лабораторіями від творців Burp Suite;
• OWASP Juice Shop — навмисно вразливий інтернет-магазин із дошкою завдань;
• DVWA — класичний вразливий PHP-застосунок із рівнями складності, розгортається локально;
• OWASP crAPI — навмисно вразливий API для практики OWASP API Top 10;
• TryHackMe — навчальні шляхи з віртуальними машинами просто в браузері, найкраще для новачків;
• Hack The Box — лабораторії, курси Academy й змагання CTF для тих, хто хоче глибше.

Коли база буде, спробуйте публічні програми bug bounty на HackerOne чи Bugcrowd — лише в межах правил (scope) конкретної програми. Більше тренажерів — у статті «Тренажери для тестувальників».

План навчання на місяць

АІ в тестуванні безпеки

АІ-асистенти, як-от GitHub Copilot, Cursor чи Claude Code, пояснюють знайдені вразливості, пропонують виправлення й допомагають писати правила Semgrep чи шаблони Nuclei. Сканери й платформи на кшталт Snyk, SonarQube і Caido додають АІ для пріоритизації знахідок і перевірки коду, згенерованого АІ, — а такий код теж може містити вразливості. Платформа HackerOne пропонує й тестування безпеки самих АІ-систем. Рішення, що вважати ризиком і як його виправити, усе одно залишається за людьми.

Про інші види тестування читайте в статтях «Інструменти для мануального тестування» та «Інструменти для автоматизації тестування». Усі інструменти з цієї статті є в підкатегоріях Тестування і Безпека коду та застосунків.

Часті запитання

Чи може мануальний тестувальник займатися безпекою?

Так. Перевірки прав доступу, введення даних і логіки — природне продовження функціонального тестування. Почніть із чек-листа вище й PortSwigger Academy.

Burp Suite чи ZAP?

Burp Suite — стандарт для ручного тестування, його Community Edition безкоштовна. ZAP повністю безкоштовний і зручніший для автоматичного сканування в CI. Багато хто використовує обидва.

Чи можна сканувати будь-який сайт, щоб потренуватися?

Ні. Без дозволу власника це незаконно. Тренуйтеся на навчальних платформах і власних локальних застосунках або в межах правил програм bug bounty.

Чим тестування безпеки відрізняється від пентесту?

Тестування безпеки — регулярна частина роботи команди: автоматичні сканери й перевірки в кожному релізі. Пентест — окремий глибокий аудит фахівцями за погодженими правилами, зазвичай кілька разів на рік або перед важливими релізами.

Не знаєте, з чого почати?

Запитайте Елю: вона підбере інструменти тестування безпеки під ваш проєкт і рівень.

Дата перевірки фактів: 4 листопада 2026 року. Умови сервісів можуть змінюватися, тож перевіряйте їх на офіційних сайтах.