"Безпека — це справа пентестерів і DevSecOps." Якщо ви так думаєте — ця стаття може змінити ваш погляд.

У 2026 QA інженер, який вміє базово тестувати безпеку API, коштує значно більше ніж той, хто цього не вміє. І для цього не потрібно ставати security фахівцем.

Чому це важливо для QA

По-перше, security баги дорогі. Злам через SQL injection коштує компанії набагато більше ніж сотні звичайних багів разом.

По-друге, security перевірки знаходяться в зоні відповідальності QA. Якщо QA перевіряє що API повертає правильні дані — він також повинен перевіряти що API не повертає дані яким не належить.

По-третє, стандарти вимагають. GDPR, PCI DSS, SOC2 — все це вимагає демонстрації що компанія тестує на безпеку. QA документація — частина доказової бази.

OWASP Top 10: коротко про найважливіше

OWASP (Open Web Application Security Project) публікує список найкритичніших вразливостей веб-застосунків. Це фактично стандарт галузі.

1. Broken Access Control

Найпоширеніша вразливість. Суть: користувач може отримати доступ до ресурсів, до яких не повинен мати доступу.

Що тестувати:

1# Тест: чи може user A бачити дані user B?
2GET /api/users/456/profile
3Authorization: Bearer <токен user A з ID 123>
4
5# Очікуємо: 403 Forbidden
6# Якщо 200 OK — вразливість IDOR (Insecure Direct Object Reference)
1# Тест: чи може звичайний user виконати admin-дію?
2DELETE /api/admin/users/456
3Authorization: Bearer <токен звичайного user>
4
5# Очікуємо: 403 Forbidden
6# Якщо 200 OK — зламаний контроль доступу

2. Cryptographic Failures (колишній Sensitive Data Exposure)

Чутливі дані передаються або зберігаються незахищено.

Що тестувати:

  • API відповідає тільки по HTTPS (HTTP повинен редиректити)
  • Паролі, токени, PII не логуються
  • Відповідь API не містить зайвих чутливих полів (хеші паролів, внутрішні ID, тощо)
1# Перевірте що в відповіді немає:
2GET /api/users/me
3
4# Відповідь НЕ повинна містити:
5{
6  "id": 123,
7  "email": "user@example.com",
8  "password_hash": "...",    // ← ВРАЗЛИВІСТЬ
9  "internal_uuid": "...",    // ← підозріло
10  "credit_card": "..."       // ← КРИТИЧНО
11}

3. Injection (SQL, NoSQL, Command)

Зловмисник вставляє код в запит і змушує систему його виконати.

SQL Injection — базова перевірка:

1# В параметрах запиту спробуйте:
2GET /api/users?id=1'
3GET /api/users?name='; DROP TABLE users; --
4GET /api/users?id=1 OR 1=1
5
6# Якщо відповідь 500 з повідомленням про помилку БД — система вразлива
7# Безпечна система: 400 Bad Request або 200 з пустим результатом

Що ще перевіряти: чи система не повертає детальні повідомлення про помилки БД (stack traces, SQL queries) в production.

4. Broken Authentication

Проблеми з авторизацією і управлінням сесіями.

Що тестувати:

1# 1. Чи можна брутфорсити пароль?
2POST /api/auth/login
3# Надішліть 100+ запитів з різними паролями — повинен бути rate limiting
4
5# 2. Чи токен валідний після logout?
6POST /api/auth/logout    # вийти
7GET /api/profile         # спробувати з тим самим токеном
8# Очікуємо: 401 Unauthorized
9
10# 3. JWT: чи можна змінити payload?
11# Декодуйте JWT і змініть role з "user" на "admin"
12# Система не повинна приймати такий токен

5. Security Misconfiguration

Сервери, бази даних або API налаштовані небезпечно.

Що перевірити:

  • HTTP headers безпеки присутні
  • Swagger/API docs не доступні в production без авторизації
  • Verbose error messages вимкнені
1# Перевірка security headers
2curl -I https://api.example.com/
3
4# Повинні бути присутні:
5# Strict-Transport-Security: max-age=31536000
6# X-Content-Type-Options: nosniff
7# X-Frame-Options: DENY
8# Content-Security-Policy: ...

6. Vulnerable and Outdated Components

Застарілі бібліотеки з відомими вразливостями. Це зазвичай поза зоною відповідальності QA, але варто знати.

7. Identification and Authentication Failures

Слабкі паролі, відсутність MFA для чутливих операцій.

Що тестувати:

  • Чи приймає система слабкі паролі ("123456", "password")?
  • Чи є блокування після N невдалих спроб?
  • Чи вимагається MFA для адмін-панелі?

8. Software and Data Integrity Failures

Перевірка що дані і оновлення приходять з довірених джерел. Актуально для CI/CD пайплайнів.

9. Security Logging and Monitoring Failures

Відсутність логування security-подій.

Що тестувати:

  • Після 10 невдалих спроб логіну — чи є alert в системі моніторингу?
  • Спроба доступу до чужого ресурсу — чи логується?

10. Server-Side Request Forgery (SSRF)

Зловмисник змушує сервер робити запити до внутрішніх ресурсів.

1# Якщо є поле для URL (аватар по URL, webhook, тощо):
2POST /api/profile/avatar
3{ "url": "http://169.254.169.254/latest/meta-data/" }  # AWS metadata
4{ "url": "http://internal-service:8080/admin" }         # внутрішні сервіси
5
6# Сервер не повинен виконувати запити до приватних адрес

Практичні інструменти

OWASP ZAP (Zed Attack Proxy)

Безкоштовний, open-source. Проксі між браузером і сервером — перехоплює запити і автоматично шукає вразливості.

1# Базовий automated scan
2docker run -t owasp/zap2docker-stable zap-baseline.py \
3  -t https://api.example.com \
4  -r zap-report.html

Burp Suite Community

Стандарт для мануального security тестування. Community версія безкоштовна. Дозволяє перехоплювати, модифікувати і повторно відправляти запити.

Postman / Bruno

Для мануальних перевірок — просто надсилайте модифіковані запити: змінені ID, SQL-символи, відсутні токени.

Мінімальний чеклист security для QA

Ось що кожен QA повинен перевіряти для кожної фічі з API:

1Авторизація:
2□ Запит без токена → 401
3□ Запит з невалідним токеном → 401
4□ Запит з токеном іншого користувача → 403 (якщо чужий ресурс)
5
6Контроль доступу:
7□ User не може робити admin-дії
8□ User А не може читати/змінювати дані User B
9□ Зміна ID в URL не відкриває чужі дані
10
11Валідація вхідних даних:
12□ SQL-символи в параметрах не ламають систему (повертає 400, не 500)
13□ Довгі рядки обробляються коректно
14□ Пусті обов'язкові поля → валідаційна помилка
15
16Чутливі дані:
17□ Паролі/токени не повертаються у відповідях
18□ Відповідь не містить зайвих внутрішніх полів
19□ HTTPS обов'язковий

Підсумок

Security testing — не чорна магія. Базові перевірки доступні кожному QA інженеру без спеціальної підготовки: надіслати запит без токена, спробувати чужий ID, додати SQL-символ в параметр.

Почніть з цього мінімального чекліста для кожної нової фічі — і ви вже робите кращу роботу ніж більшість QA команд.

Для поглиблення: OWASP Testing Guide — безкоштовний, детальний і є стандартом галузі.