Основы тестирования безопасности, которые должен знать каждый QA-инженер

Ввести одинарную кавычку ' в любое текстовое поле и посмотреть на ошибку базы данных: это базовая проверка SQL-инъекции которая занимает десять секунд и не требует никаких security-инструментов. Подменить ID ресурса другого пользователя в URL и проверить получишь ли доступ: это проверка на broken object-level authorization, одну из самых распространённых уязвимостей API, и она уже входит в область QA при функциональном тестировании. Статья разбирает проверки аутентификации, авторизации, валидации ввода и cookie которые QA-инженеры могут запускать без специалистов, с Playwright-примерами для тех из них которые стоит автоматизировать.

Что QA-инженеры могут тестировать без специализированных инструментов

Аутентификация и управление сессиями

Самые распространённые баги безопасности находятся в auth-флоу. Тестируй при обычном функциональном тестировании.

Авторизация (контроль доступа)

Здесь прячется большинство серьёзных багов.

GET /api/orders/12345   ← заказ пользователя A

Войди как пользователь B и обратись по тому же URL. Что происходит?

Валидация ввода

Каждое поле формы: потенциальная точка инъекции.

Эти ручные тесты быстрые и ловят очевидные уязвимости. Они не заменяют автоматизированное security-сканирование, но стоят запуска на каждой новой фиче.

HTTPS и cookie

Проверяй в DevTools браузера:

• Сайт работает по HTTPS? HTTP редиректит на HTTPS?
• Сессионные cookie помечены HttpOnly (недоступны из JavaScript)?
• Сессионные cookie помечены Secure (передаются только по HTTPS)?
• Для auth-cookie установлен SameSite в Strict или Lax?

В Playwright:

test('auth cookie has security flags', async ({ page, context }) => {
  await page.goto('/login');
  // ... выполняем вход
  
  const cookies = await context.cookies();
  const sessionCookie = cookies.find(c => c.name === 'session_token');

  expect(sessionCookie?.httpOnly).toBe(true);
  expect(sessionCookie?.secure).toBe(true);
  expect(sessionCookie?.sameSite).toMatch(/strict|lax/i);
});

Сообщения об ошибках и раскрытие информации

Слишком информативные сообщения об ошибках: проблема безопасности.

• "Пользователь не найден" против "Неверные учётные данные": первое говорит атакующим какие аккаунты существуют
• Стек-трейсы в ответах продакшна
• Внутренние пути сервера, имена баз данных или версии библиотек в сообщениях об ошибках
• API-ответы с полями вроде passwordHash, internalId или флагами администратора

Как интегрировать security в процесс тестирования

Базовое сканирование OWASP ZAP

OWASP ZAP бесплатен и может работать как пассивный сканер параллельно с Playwright-тестами. Режим baseline scan обходит приложение и сигнализирует об очевидных проблемах:

# .github/workflows/security.yml
- name: ZAP Baseline Scan
  uses: zaproxy/action-baseline@v0.10.0
  with:
    target: 'https://staging.myapp.com'
    rules_file_name: '.zap/rules.tsv'

Ловит отсутствующие security-заголовки, небезопасные cookie и раскрытую информацию о сервере без написания тест-кода.

Проверка security-заголовков

Заголовки которые должно отправлять приложение:

Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin

Тест в Playwright:

test('security headers are present', async ({ request }) => {
  const response = await request.get('https://myapp.com');
  const headers = response.headers();

  expect(headers['x-content-type-options']).toBe('nosniff');
  expect(headers['x-frame-options']).toBe('DENY');
  expect(headers['strict-transport-security']).toContain('max-age=');
});

Что передавать security-специалистам

Часть security-тестирования требует специализированных навыков и инструментов:

• Полное пентестирование
• Анализ бинарных файлов
• Ревью криптографии
• Безопасность инфраструктуры (облачная конфигурация, сегментация сети)
• Тестирование социальной инженерии

Когда находишь потенциальную проблему безопасности через ручное тестирование: документируй чётко (шаги воспроизведения, потенциальное влияние) и эскалируй в security-команду или фиксируй как баг с высокой серьёзностью. Не пытайся самостоятельно доказать эксплуатируемость. Твоя задача: найти, а не эксплуатировать.

Лучшая security-позиция: эшелонированная защита. QA ловит очевидные проблемы в процессе разработки, автоматизированные сканеры ловят системные проблемы в CI, специалисты делают глубокое ревью перед крупными релизами.