Безпека — вже не тільки про пентестерів. QA інженери повинні знати базові security перевірки. Розбираємо OWASP Top 10 і що перевіряти в API без спеціалізованих знань.

Security testing для QA: OWASP Top 10 і базові перевірки безпеки API

"Безпека — це справа пентестерів і 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

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

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

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

# Тест: чи може звичайний user виконати admin-дію?
DELETE /api/admin/users/456
Authorization: Bearer <токен звичайного user>
 
# Очікуємо: 403 Forbidden
# Якщо 200 OK — зламаний контроль доступу

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

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

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

API відповідає тільки по HTTPS (HTTP повинен редиректити)
Паролі, токени, PII не логуються
Відповідь API не містить зайвих чутливих полів (хеші паролів, внутрішні ID, тощо)

# Перевірте що в відповіді немає:
GET /api/users/me
 
# Відповідь НЕ повинна містити:
{
  "id": 123,
  "email": "user@example.com",
  "password_hash": "...",    // ← ВРАЗЛИВІСТЬ
  "internal_uuid": "...",    // ← підозріло
  "credit_card": "..."       // ← КРИТИЧНО
}

3. Injection (SQL, NoSQL, Command)

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

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

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

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

4. Broken Authentication

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

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

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

5. Security Misconfiguration

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

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

HTTP headers безпеки присутні
Swagger/API docs не доступні в production без авторизації
Verbose error messages вимкнені

# Перевірка security headers
curl -I https://api.example.com/
 
# Повинні бути присутні:
# Strict-Transport-Security: max-age=31536000
# X-Content-Type-Options: nosniff
# X-Frame-Options: DENY
# 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)

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

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

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

OWASP ZAP (Zed Attack Proxy)

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

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

Burp Suite Community

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

Postman / Bruno

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

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

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

Авторизація:
□ Запит без токена → 401
□ Запит з невалідним токеном → 401
□ Запит з токеном іншого користувача → 403 (якщо чужий ресурс)

Контроль доступу:
□ User не може робити admin-дії
□ User А не може читати/змінювати дані User B
□ Зміна ID в URL не відкриває чужі дані

Валідація вхідних даних:
□ SQL-символи в параметрах не ламають систему (повертає 400, не 500)
□ Довгі рядки обробляються коректно
□ Пусті обов'язкові поля → валідаційна помилка

Чутливі дані:
□ Паролі/токени не повертаються у відповідях
□ Відповідь не містить зайвих внутрішніх полів
□ HTTPS обов'язковий

Підсумок

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

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

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