Автоматизація security-перевірок для AQA/SDET

Що таке security-асерт і чим він відрізняється від звичайного асерту?

Технічно — нічим, крім предмета. Це та сама перевірка в тому самому ранері, просто дивиться вона не на текст на екрані, а на властивість відповіді, від якої залежить безпека: код відмови, прапорці кукі, заголовок, стан ресурсу на сервері після дії. Окремого жанру «тест на безпеку» тут не заводять — заводять звичайний тест із іншим предметом асерту. Практичний наслідок один, але важливий: автотест не вміє перевіряти абстрактну «захищеність», тож будь-яку вимогу спершу треба перекласти у конкретне поле відповіді. Поки вимога звучить як «чужі дані не мають бути доступні», асерту немає; коли вона звучить як «GET на чужий рахунок повертає 403» — асерт є.

Куди в пайплайні ставлять security-перевірки і чим визначається місце конкретної?

Канон OWASP не будує окремий «процес безпеки» збоку від наявного пайплайна (pipeline) — він додає кроки в той самий пайплайн, а мету формулює через швидкість: дефект дизайну чи вразливість мають знайтися якомога раніше. Порядок стадій задає й порядок кроків: моделювання загроз ще до коду, далі pre-commit із керуванням секретами й лінтингом, далі власне сканування (SAST, DAST, IAST, SCA, інфраструктура, контейнери), а наприкінці — аудит відповідності. Місце конкретної перевірки визначає не «рівень», а її вхід: аналізатору коду потрібен репозиторій, динамічному сканеру — жива ціль, до якої він достукається по мережі, асерту — вже отримана відповідь сервера. Про піраміду тестування ці джерела не говорять узагалі, тож відповідь «security-тести живуть на рівні інтеграційних» — вигадка, а не канон. Ще дві речі, які варто згадати: перед деплоєм у прод лишають ручний апрув, а дефолтним налаштуванням вендора сліпо не довіряють.

Чому в тесті на заборонений доступ не можна асертити res.ok()?

Бо ok() — це не «сервер повівся правильно», а буквально «код у діапазоні 200–299». Для перевірки прав це фатально: і 403, і 404, і 401, і навіть 500 дадуть однакове false, а різниця між ними — власне предмет тесту. Тест із таким асертом лишиться зеленим і тоді, коли сервер зламався й віддає 500 замість чесної відмови. Перевіряти треба status() і конкретне число з контракту: 403, якщо продукт визнає існування ресурсу, або 404, якщо він навмисно приховує сам факт його існування. Той самий асерт заодно ловить дзеркальну знахідку — коли замість відмови приходить 200.

Як правильно перевірити прапорці сесійної кукі у відповіді?

Тільки через масив заголовків, не через обʼєкт. Обʼєктна форма зводить заголовки до пар «імʼя — значення», тож із кількох Set-Cookie в одній відповіді тест побачить рівно один; решта зникає мовчки, без помилки й без попередження. А Set-Cookie — саме той заголовок, який дока наводить прикладом множинного: в масиві він зʼявляється стільки разів, скільки його надіслав сервер. Виходить найгірший різновид зеленого тесту: перевірка HttpOnly пройшла, але не на тій куці. Правильно взяти масив заголовків, відфільтрувати всі записи з іменем set-cookie (порівняння імені — без урахування регістру) і перевірити прапорці на кожному або хоча б адресно на потрібному. У WebDriver ситуація простіша: там для цього є вбудовані методи — прочитати одну куку за іменем або забрати всі одразу з поточної сесії, — а перелік полів, які повертаються, задає сама специфікація.

Тест логіниться і одразу перевіряє сесійну куку. Іноді червоний. Чому?

Майже завжди — через момент асерту. Логін рідко буває одним запитом: типово це ланцюг редиректів, і кукі виставляються в різних його ланках. Асерт, зроблений одразу після сабміту форми, перевіряє проміжний стан, у якому потрібної кукі ще немає, — звідси й плаваюче падіння, що залежить від швидкості середовища. Дока Playwright підписує цю пастку прямо в прикладі логіну, а лікування пропонує не паузою: треба дочекатися кінцевого URL флоу й перевіряти вже після нього. Фіксований waitForTimeout тут не рішення, а маскування — на повільному CI він знову не встигне. Побічний ефект того самого ланцюга є і в TLS-даних: для редиректу повертаються дані останнього запиту, а для не-HTTPS — null, тож перевірка сертифіката без перевірки самої наявності даних мовчки проходить на порожнечі.

Кандидат каже: «кнопки в інтерфейсі немає, отже, доступ закрито». Що з цим не так?

Це не контроль доступу, а приховування в UI, і воно обходиться без жодних інструментів — прямим запитом до ендпоінта з валідною сесією звичайного користувача. OWASP формулює це як вимогу: рубіж має тримати API, а стан інтерфейсу перевіркою прав не є. Для автотесту звідси випливає конкретна дисципліна: сценарій «елемента не видно» доповнюється сценарієм «прямий виклик відповідає 403 або 404». Є й акуратний прийом перевірити, хто саме тримає рубіж: у Playwright офіційний приклад зміни запиту — це видалення заголовка перед route.continue(). Прибрали службовий заголовок, який слухняно шле клієнт, і дивимось, чи сервер усе ще відмовляє; якщо доступ раптом зʼявився — контроль жив на клієнті.

Які негативні коди варто покривати в API-тестах, крім 401 і 403?

Шпаргалка OWASP REST Security дає готовий перелік, з якого очікування виводяться майже механічно. 405 — виклик методом поза списком дозволених для ресурсу. 429 — перевищення дозволеної частоти запитів. 413 — завеликий пейлоад. 406 або 415 — запит із неочікуваним чи взагалі відсутнім типом вмісту (виняток джерело робить тільки для порожнього тіла). Плюс базова пара: 401 означає, що автентифікаційних даних немає або вони криві, 403 — що користувача впізнали, але прав на цей ресурс у нього немає. І окремий пункт, який часто забувають: перевіряти треба не лише код, а й тіло. Стек-трейс, назва фреймворку, шлях у файловій системі чи текст SQL-помилки — це знахідка навіть тоді, коли статус ідеально правильний.

Що перевіряють у JWT автотестами?

Найперше — що сервер не приймає незахищений токен з alg: none і не обирає алгоритм перевірки з заголовка самого токена: інакше підпис перевіряється тим, що запропонував нападник. Далі — обовʼязковий мінімум клеймів: iss, aud, exp, nbf; токен без них або з простроченим exp має бути відхилений. Найцікавіший сценарій — запит валідним за формою токеном уже після логауту: підписаний токен цілком здатен пережити власну сесію, бо ні натиснутий вихід, ні спрацьований таймаут самі по собі підпису не псують, — і саме тут видно, чи спирається сервер лише на криптографію, чи ще й на серверний стан сесії. Перевіряти це зручно на рівні API: логін, збереження токена, логаут, той самий токен у заголовку — і асерт на відмову, а не на 200.

Що таке перевірка порядку кроків процесу і чому звичайні тести прав її не замінюють?

Це перевірка того, чи можна викликати ендпоінти багатокрокового флоу поза послідовністю: одразу підтвердити замовлення, не оплативши; повернутися на попередній крок після завершення; перевикористати токен одного кроку на іншому. Тести ролей цього не ловлять структурно: кожен виклик REST авторизується самостійно й нічого не знає про те, які кроки вже пройдено, тож усі виклики можуть бути «дозволені» окремо, а разом складатися в обхід процесу. Практично це виглядає як два питання до кожного ендпоінта ланцюга: чи валідує він поточний стан і чи не приймає він артефакт, виданий для іншого кроку. Автоматизується це звичайним API-тестом, який просто робить кроки не в тому порядку й асертить відмову.

Навіщо матрицю авторизації виносити в окремий файл, а не писати тести руками?

Бо ламається авторизація не на старті, а в наступних релізах: фічі додають і змінюють, не оцінюючи, як це зачепило наявні права — саме це джерело називає головною причиною проблем із авторизацією, а надбудова над ним говорить про проблему «другого дня». Матриця у файлі перетворює правила з тексту в артефакт, який читають і людина, і програма: правил у собі тести не дублюють — вони читають файл і множать сервіси на точки зору. Наслідків два. Перший — нову роль чи новий сервіс додають правкою одного файлу, а не десятком нових тестів. Другий — покриття перестає бути вибірковим: у файлі видно порожні клітинки, а в купі рукописних тестів не видно нічого. І дозволені клітинки набір перевіряє нарівні з забороненими — інакше сюїта зеленітиме на сервері, який відмовляє геть усім.

Що таке POV і як має виглядати падіння тесту, згенерованого з матриці?

POV (Point Of View) — це роль, від імені якої йде конкретний прогін: анонім, звичайний користувач, менеджер, адміністратор. Один тест-кейс на точку зору дає корисний побічний ефект — результати профілюються за рівнем доступу, і одразу видно, чи «протікає» саме анонім, чи вже автентифікований користувач. Падіння має бути самодостатнім: воно називає сервіс, точку зору, фактичний код і очікуваний — на кшталт «сервіс видалення повідомлення, POV анонім: отримали 200, очікували 403». Це не косметика: у згенерованому наборі сотні кейсів, і повідомлення «expected 403, received 200» без координат змушує лізти в код генератора замість того, щоб іти до розробника з готовим фактом. У Playwright це робиться другим аргументом до expect — повідомленням, зібраним із тих самих полів матриці.

У якому форматі зберігати матрицю — таблиця чи JSON/YAML?

Тут канон суперечить сам собі, і найсильніша відповідь — знати про це, а не обирати сторону навмання. Шпаргалка Authorization Testing Automation описує матрицю саме як таблицю (spreadsheet), а приклад тримає у XML. Шпаргалка Authorization Regression Testing вимагає прямо протилежного: зберігати матрицю в машиночитному форматі — JSON, YAML або структуровані фікстури — саме щоб фреймворк генерував кейси динамічно й ручна підтримка не росла разом із політикою. Обидва документи чинні, причому другий позиціює себе як надбудову над першим і додає до нього вимір безперервної регресії. Практична користь від цього знання дуже приземлена: суперечку на ревʼю «чому в нас YAML, а не табличка» вирішує цитата з потрібного документа, а не аргументи про зручність.

Які патерни регресії авторизації ганяють по матриці?

Три. Горизонтальна ескалація (вона ж IDOR): користувач B тієї самої ролі намагається прочитати, змінити й видалити ресурс користувача A — очікується 403 або 404, і ніколи 200. Вертикальна ескалація: усі неадміністративні точки зору, включно з анонімною, стукають в адміністративні ендпоінти; перевірку тут робить API, а сховані в інтерфейсі кнопки не рахуються взагалі. Ізоляція тенантів: користувач одного тенанта робить широкий читальний запит по даних іншого, і критерій провалу тут найжорсткіший — досить одного чужого ідентифікатора запису у відповіді, щоб вважати це критичним збоєм. Окремий важіль поверх цих трьох — контракт: якщо специфікація вимагає для ендпоінта конкретний скоуп, набір має сам перевіряти, що токен без нього отримує 401 або 403. І перевіряти це треба на кожному ендпоінті, бо кожен виклик REST авторизується окремо.

Що поставити в CI — ZAP baseline чи повний скан?

Це питання про ціну, а не про «який кращий». Baseline пускає павука по цілі (типово хвилину), чекає завершення пасивного сканування і жодних атак не виконує — тому він триває кілька хвилин, ставиться в кожен прогін і придатний навіть проти продакшну. Повний скан — це вже DAST з активним скануванням без ліміту часу для павука, тобто справжні атаки по цілі; його README відкривається окремим попередженням саме про це. Побічні ефекти теж різні: активний скан сабмітить форми, тож форма зворотного звʼязку й коментарі полетять реальними повідомленнями живим людям. Звідси й практична різниця: baseline безпечний для регулярного прогону, а повний скан у кожному пул-реквесті — це довго й шумно, тож він потребує дозволу на ціль і попередження не лише власника застосунку, а й хостингу з CDN. Конкретного розкладу для повного скану (нічний прогін, перед релізом, щотижня) джерела не задають — це вже домовленість команди. Поза цією парою існує ще й окремий скан під API: активний прогін по ендпоінтах, які описує OpenAPI або GraphQL.

ZAP у пайплайні нічого не знайшов. Які є пояснення, крім «застосунок чистий»?

Найчастіше — сканер просто не достукався до цілі. За замовчуванням застосунок в одному контейнері Docker не бачить застосунку в іншому, тож у типовій CI-збірці «сканер у контейнері, застосунок у сусідньому» прогін проходить успішно й порожньо. Друге пояснення — образ: найлегший bare пакетних сканів взагалі не містить, тож запуск може не робити того, що ви думаєте. Третє — конфігурація правил: після першого прогону генерують конфіг-файл параметром -g, і в ньому кожне правило можна перевести у IGNORE; надто щедрий IGNORE робить звіт порожнім законно. До речі, відомий борг правильніше виносити не в IGNORE, а в progress-файл, де знахідки позначаються як IN-PROGRESS: тоді у звіті видно саме нові, а не тишу. І окремо варто памʼятати, що GitHub-дії ZAP — не інший сканер: вони обгортають ті самі пакетні скани, ведуть issue з алертами й кладуть звіт артефактом.

Що таке code scanning на GitHub і до чого тут SARIF?

Code scanning — функція GitHub для аналізу коду прямо в репозиторії: вона шукає вразливості безпеки й помилки кодування, а знахідки показує там, де лежить сам код. Працює вона на два фронти — розгрібає борг, який уже накопичився, і не пускає новий, — а тригером служить пуш, інша подія репозиторію або розклад. Результат вимірюється алертами, і закриваються вони самі: щойно виправлено код-причину, алерт зникає. Ключове для розуміння меж: це радше майданчик для аналізаторів, ніж конкретний аналізатор — поруч із CodeQL підключається будь-який сторонній інструмент, навіть запущений у чужому CI, бо сумісність забезпечує спільний формат обміну результатами статичного аналізу (Static Analysis Results Interchange Format, SARIF). Обмеження теж варто назвати: прогін їсть хвилини GitHub Actions, приватним репозиторіям потрібна ліцензія Code Security, а порожній звіт двозначний — так само виглядає і чистий код, і аналізатор, який не відпрацював; ці випадки розводить окрема сторінка стану інструментів.

Security-крок у пайплайні зелений. Що це доводить?

Саме по собі — майже нічого, поки не перевірені чотири речі. Перша: як інструмент класифікував знахідки. У ZAP усі алерти типово вважаються попередженнями, а не помилками, і в FAIL їх переводить рішення по кожному правилу в конфізі; плюс існує прапорець -I, який знімає падіння на попередженнях узагалі. Друга: чи читає обгортка код виходу контейнера. Обидві GitHub-дії ZAP за замовчуванням не валять статус кроку, навіть коли контейнер повернув ненульовий код, — для цього треба виставити fail_action: true (і памʼятати дзеркальний ефект: тоді крок червоніє на будь-яких алертах, а не лише на переведених у FAIL). Третя: чи є перевірка required check — бо червоний крок, який не блокує мердж, гейтом не є; сенс набору регресії авторизації існує рівно доти, доки він не пускає вразливий код у мердж. Четверта: чи інструмент узагалі відпрацював і побачив ціль — крок, який зеленіє на невдалому запуску, виглядає точно як пройдений гейт. Мовчить будь-яка з цих ланок — знахідка не блокує нічого.

Червоний npm audit у пайплайні — це завжди нова вразливість?

Ні, і це друга половина тієї самої пастки з кодами виходу. Аудит має параметр, який задає мінімальний рівень вразливості для ненульового коду виходу — від info до critical, з окремим значенням none, — тож червоний колір спершу треба звірити з тим, що саме команда домовилася вважати падінням. Але є й окремий випадок: ненульовий код приходить і тоді, коли фікс існує, просто політика свіжості релізу не дозволила поставити пропатчену версію — тоді пакет лишається вразливим, а команда попереджає, що виправлення заблоковано. Тобто червоне може означати не «зʼявилася нова діра», а «фікс є, але його не пустила ваша ж конфігурація». Практичний висновок: перш ніж заводити тікет на залежність, читайте текст виводу, а не колір кроку.

Який рівень вразливості має валити білд?

Це питання-пастка на вигадану цифру. Джерела, які описують цю механіку, порогу не задають: вони дають інструменти — класифікацію правил у конфізі, прапорець зняття падіння, коди виходу, перемикач падіння статусу в обгортці, мінімальний рівень для аудиту залежностей, — а політику лишають команді. Так само в них немає ні описаної процедури винятку повз гейт, ні межі між блокуючим і попереджувальним гейтом. Сильна відповідь на співбесіді каже це прямо, а далі переводить розмову в площину процесу: хто ухвалює поріг, як оформлюється тимчасовий виняток, куди девається відомий борг (у progress-файл, а не в глухий IGNORE) і як команда відрізняє «нова знахідка» від «стара, вже прийнята». Назвати навмання «high і вище валить білд» гірше, ніж чесно сказати, що канон цього не встановлює.

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

Кейс 1. Тест, який брехав: три асерти на відповідь

У сюїті є тест «менеджер не має доступу до чужого рахунку». Він зелений півроку. Насправді він зелений незалежно від того, працює контроль доступу чи ні. Ось як він виглядав:

// БУЛО: три асерти, жоден з яких не перевіряє того, що написано в назві тесту
test('менеджер не бачить чужий рахунок', async ({ page, request }) => {
  await page.goto('/accounts/9931');
  await expect(page.getByTestId('withdraw-button')).toBeHidden(); // 1

  const res = await request.get('/api/accounts/9931', {
    headers: { Authorization: `Bearer ${managerToken}` },
  });
  expect(res.ok()).toBeFalsy();                                    // 2

  const cookie = res.headers()['set-cookie'];
  expect(cookie).toContain('HttpOnly');                            // 3
});

Той самий тест після ремонту:

// СТАЛО: предмет кожного асерту — конкретне поле відповіді
test('менеджер не бачить чужий рахунок', async ({ page, request }) => {
  const res = await request.get('/api/accounts/9931', {
    headers: { Authorization: `Bearer ${managerToken}` },
  });

  // 403 — впізнали, але не можна; 404 був би теж валідним, якщо так каже контракт
  expect(res.status(), 'чужий рахунок віддали замість відмови').toBe(403);

  // у тілі відмови не має бути технічних деталей
  const body = await res.text();
  expect(body).not.toMatch(/stack|Traceback|at .+\(.+:\d+:\d+\)/i);

  // прапорці — з масиву: Set-Cookie у відповіді буває кілька
  const setCookie = res
    .headersArray()
    .filter((h) => h.name.toLowerCase() === 'set-cookie');
  for (const h of setCookie) {
    expect(h.value, `кука без HttpOnly: ${h.value.split('=')[0]}`).toMatch(/HttpOnly/i);
  }
});

Що дивитися і чому:

• Асерт 1 перевіряв дизайн, а не право. Схована кнопка означає рівно те, що її не намалювали; ендпоінт при цьому доступний прямим запитом із валідною сесією. Рубіж має тримати API, тож сценарій «елемента не видно» — доповнення до перевірки доступу, а не її заміна.
• Асерт 2 приймав будь-яку катастрофу за успіх. Прапорець успішності — це діапазон 200–299, тож 403 (правильна відмова), 404, 401 і 500 (сервер упав) дають однакове false. Тест лишався б зеленим і після того, як ендпоінт почав падати з винятком. Число з контракту в status() розводить ці випадки.
• Асерт 3 перевіряв не ту куку. Обʼєктна форма заголовків зводить їх до пар «імʼя — значення», а Set-Cookie в одній відповіді буває кілька — саме цей заголовок дока наводить прикладом множинного. Перевірка мовчки бачила одну з них; масив заголовків повертає всі записи, і саме на масиві прапорці перевіряються чесно.
• Момент перевірки — окрема пастка. Якщо куку дивитися одразу після сабміту форми логіну, асерт може прийти в середину ланцюга редиректів, де потрібної кукі ще немає: тест буде плавати залежно від швидкості середовища. Чекати треба кінцевого URL флоу, а не фіксованої паузи.
• Хто саме тримає рубіж — перевіряється прибиранням заголовка. Якщо клієнт слухняно шле службовий заголовок, приберіть його на льоту й подивіться, чи сервер усе ще відмовляє:

await page.route('**/api/**', async (route) => {
  const headers = route.request().headers();
  delete headers['x-admin-mode']; // клієнт більше не «підтверджує» свої права
  await route.continue({ headers });
});

Кейс 2. Матриця ролей як файл, з якого ростуть тести

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

{
  "roles": [
    { "name": "ANONYMOUS", "headers": {} },
    { "name": "USER",      "headers": { "Authorization": "Bearer {{token.user}}" } },
    { "name": "MANAGER",   "headers": { "Authorization": "Bearer {{token.manager}}" } },
    { "name": "ADMIN",     "headers": { "Authorization": "Bearer {{token.admin}}" } }
  ],
  "services": [
    { "name": "ListInvoices",  "method": "GET",    "url": "/api/invoices",
      "allowedRoles": ["USER", "MANAGER", "ADMIN"] },
    { "name": "DeleteInvoice", "method": "DELETE", "url": "/api/invoices/{{id.own}}",
      "allowedRoles": ["ADMIN"] },
    { "name": "ExportTenant",  "method": "GET",    "url": "/api/tenants/{{id.tenant}}/export",
      "allowedRoles": ["ADMIN"] }
  ],
  "services-testing": [
    { "name": "DeleteInvoice", "payload": { "reason": "audit" } }
  ]
}

Генератор не знає доменної логіки — він знає лише, дозволена клітинка чи ні:

import matrix from './authorization-matrix.json';
import { resolve } from './placeholders'; // підставляє токени й ідентифікатори прогону

for (const service of matrix.services) {
  for (const pov of matrix.roles) {
    const allowed = service.allowedRoles.includes(pov.name);
    const expected = allowed ? 200 : 403;

    test(`${service.name} · POV ${pov.name}`, async ({ request }) => {
      const res = await request.fetch(resolve(service.url), {
        method: service.method,
        headers: resolve(pov.headers), // підміна токена, не повторний логін
        data: matrix['services-testing'].find((s) => s.name === service.name)?.payload,
      });

      expect(
        res.status(),
        `${service.name} · POV ${pov.name}: очікували ${expected}`,
      ).toBe(expected);
    });
  }
}

Падіння читається без відкривання коду:

1) DeleteInvoice · POV ANONYMOUS
   Error: DeleteInvoice · POV ANONYMOUS: очікували 403
   Expected: 403
   Received: 200

Таблиця рішень, за якою заповнюється колонка «очікуємо»:

Що дивитися і чому:

• Файл — джерело істини, тести — похідне. Нова роль додається одним записом у roles, і набір одразу перевіряє її на всіх сервісах. Правило, переписане в код тесту, живе окремо від правила в голові команди — і розходиться з ним уже на другому релізі.
• Формат обирає не смак, а джерело. Одна шпаргалка OWASP описує матрицю як таблицю з прикладом у XML, друга прямо вимагає машиночитного формату — JSON, YAML або структурованих фікстур — саме заради динамічної генерації. Обидві чинні, тож на ревʼю це закривається посиланням, а не суперечкою.
• Перемикання ролі — підміна токена. Джерело вимагає саме дешевого перемикання контексту автентифікації, без повного логіну на кожен тест: повний логін на кожну комбінацію роздуває прогін і додає власних причин для флаку.
• Набір йде в тому самому пайплайні, що функціональний, і виділяється тегом чи окремим скриптом — щоб локально ганяти вибірково, а в CI цілком.
• Сигнал на межі теми: різкий стрибок кількості 401/403 у прогоні заслуговує окремого рядка у звіті. Так виглядає функціональна правка, яка ненароком переставила комусь права, — навіть коли жоден тест не почервонів.

Кейс 3. Розтин зеленого security-кроку

Пайплайн має крок зі сканером, він зелений уже кілька місяців, і команда вважає, що безпека перевіряється. Аудит починається не зі сканера, а з питання «хто тут узагалі читає результат як падіння».

      - name: ZAP baseline
        uses: zaproxy/action-baseline # версію дії закріпіть за вашою політикою
        with:
          target: https://staging.example.com
          rules_file_name: .zap/rules.tsv
          cmd_options: '-I'      # ← знімає падіння на попередженнях
        # fail_action не виставлено   ← крок не почервоніє навіть на ненульовому коді

Файл правил після генерації параметром -g виглядає так (ідентифікатори підставляє сам ZAP):

# ідентифікатор	рішення	назва правила
NNNNN	IGNORE	(Timestamp Disclosure)
NNNNN	WARN	(X-Content-Type-Options Header Missing)
NNNNN	FAIL	(Content Security Policy (CSP) Header Not Set)

Коди виходу самого скрипта:

Далі — чотири питання, і зелений колір має пережити всі чотири:

Що дивитися і чому:

• Дефолт працює проти вас. Усі знахідки ZAP типово вважаються попередженнями, а не помилками, і рішення «що з цим робити» ухвалюється по кожному правилу окремо — у згенерованому файлі. Поки цього файлу немає, ви не налаштували гейт, ви прийняли чужий дефолт.
• Прапорець -I і відсутній fail_action — дві незалежні заглушки. Перша не дає скрипту повернути падіння на попередженнях, друга не дає обгортці прочитати ненульовий код контейнера. Прибрати треба обидві, і памʼятати дзеркальний ефект: увімкнений fail_action валить крок на будь-якому алерті, включно з тими, що лишилися попередженнями.
• Червоний крок — ще не гейт. Поки перевірка не є обовʼязковою (required check), падіння нічому не заважає: пул-реквест мерджиться поверх червоного. Сенс набору регресії авторизації існує рівно доти, доки він не пускає вразливий код у мердж.
• Найтихіша ланка — інструмент, який не відпрацював. Контейнер за замовчуванням не бачить застосунку в сусідньому контейнері, а найлегший образ bare пакетних сканів узагалі не містить: прогін «успішний і порожній» на вигляд не відрізняється від чистого застосунку. Те саме зі сканером коду — порожній звіт має два пояснення, і гейт їх не розводить.
• Відомий борг — у progress-файл, не в IGNORE. Позначка IN-PROGRESS лишає знахідку у звіті, але прибирає її з нових; глухий IGNORE прибирає її з поля зору назавжди, разом із регресією, яка колись прийде тим самим правилом.
• Червоний аудит залежностей читайте текстом, а не кольором. Ненульовий код виходу приходить і тоді, коли фікс існує, але його заблокувала політика свіжості релізу — тікет «нова вразливість» у такому разі буде неправдою. А порогу «яка severity валить білд» жодне з цих джерел не задає: інструменти вам дали, домовлятися про межу доведеться самим.

Місце в пайплайні

• Розумію модель «додані кроки», а не «окремий процес поруч»: security-перевірки вбудовують у наявний пайплайн заради швидкості знахідки, а перед деплоєм у прод лишають ручний апрув, і дефолтні налаштування вендора апріорі довірою не користуються.
• Можу назвати порядок стадій (моделювання загроз до коду → pre-commit із секретами й лінтом → сканування: SAST, DAST, IAST, SCA, інфраструктура, контейнери → аудит відповідності) і памʼятаю, що рівня в піраміді тестування канон цим перевіркам не призначає: місце визначає вхід перевірки — репозиторій, піднятий застосунок чи відповідь сервера.

Асерт на відповідь, а не на екран

• Розумію, що предмет security-асерту — поля відповіді (код, заголовки, кукі, TLS-дані, стан на сервері), а не стан інтерфейсу, і що виклик до HTTP-API з UI-тесту потрібен саме для перевірки постумов після дії в браузері.
• Знаю, чому ok() не годиться для негативного сценарію: це лише «код між 200 і 299», тому правильна відмова й падіння сервера повертають однакове false — асертити треба status() і конкретне число з контракту.
• Памʼятаю, що прапорці кукі читаються тільки з масиву заголовків: обʼєктна форма лишає по одному запису на кожне імʼя заголовка, тоді як Set-Cookie в одній відповіді буває кілька (саме його дока наводить прикладом множинного заголовка) — перевірка мовчки пройде не на тій куці.
• Знаю дві часові пастки: сесійна кука виставляється через ланцюг редиректів (чекати кінцевого URL, а не фіксованої паузи), а TLS-дані для не-HTTPS повертаються порожніми й для редиректу описують останній запит ланцюга — «сертифікат ок» і «дані не дивилися» на вигляд однакові.

Негативні сценарії API

• Можу перелічити коди відмови як окремі очікування: 401 — автентифікації немає або вона крива, 403 — впізнали, але прав немає, 405 — метод поза дозволеними, 429 — перевищення частоти, 413 — завеликий пейлоад, 406/415 — неочікуваний тип вмісту; і перевіряю не лише код, а й тіло, бо стек-трейс чи внутрішні деталі — знахідка навіть при правильному статусі.
• Знаю мінімум перевірок JWT: відмова на незахищений токен (alg: none), заборона брати алгоритм перевірки із заголовка самого токена, обовʼязкові клейми iss, aud, exp, nbf і сценарій «запит валідним токеном після логауту».
• Розумію, чому обхід порядку кроків процесу не ловиться тестами ролей: кожен виклик REST авторизується самостійно й нічого не знає про пройдені кроки, тож перевіряти треба валідацію поточного стану й перевикористання токенів між кроками.

Матриця авторизації як код

• Можу пояснити причину виносити матрицю у файл — права ламає не перший реліз, а наступні: фічу додали чи змінили, впливу на дозволи не оцінили (проблема «другого дня»), тож прогін потрібен на кожен реліз, — і знаю анатомію: два виміри (фіча й логічна роль) плюс необовʼязковий третій (дані), роль під час прогону зветься точкою зору (Point Of View, POV), а файл-півот складається з блоків roles, services і services-testing, де значення у фігурних дужках {} — плейсхолдери під час прогону.
• Памʼятаю вимоги до набору: один кейс на точку зору (щоб результати профілювались за рівнем доступу), дозволений і заборонений доступ рівноправні, перемикання ролі — підміною токена, а не повторним логіном, і падіння називає сервіс, POV, фактичний та очікуваний код.
• Знаю, що канон про формат матриці суперечить сам собі: одна шпаргалка OWASP описує її як таблицю з прикладом у XML, друга вимагає машиночитного формату (JSON, YAML, структуровані фікстури) саме заради динамічної генерації кейсів — і що друга позиціює себе надбудовою над першою.
• Можу назвати три патерни регресії й критерій кожного: горизонтальна ескалація (IDOR) — чужий ресурс дає 403 чи 404, але ніколи 200; вертикальна — усі неадмінські POV, включно з анонімом, стукають в адмінські ендпоінти, і вердикт виносить API; ізоляція тенантів — навіть один чужий ідентифікатор запису у відповіді вважається критичним збоєм.

ZAP у пайплайні

• Знаю, що baseline — це скрипт із Docker-образів ZAP (павук типово хвилину плюс пасивне сканування), він не виконує атак, триває лічені хвилини й придатний навіть проти продакшну.
• Розумію ціну повного скану: це DAST з активним скануванням і павуком без ліміту часу, тобто реальні атаки по цілі та сабміт форм — попереджати треба не тільки власника застосунку, а й хостинг із CDN; окремо існує активний скан по API, описаних OpenAPI або GraphQL.
• Памʼятаю дві деталі оточення, які роблять прогін безглуздим: образ bare пакетних сканів не містить, а контейнер за замовчуванням не дістає застосунку в сусідньому контейнері — «нічого не знайшов» часто означає «не достукався».

Сканування коду й гейт

• Знаю, що code scanning — це місце для аналізаторів, а не один аналізатор: CodeQL або сторонній інструмент (у тому числі із зовнішнього CI) підключається через формат обміну результатами статичного аналізу (Static Analysis Results Interchange Format, SARIF), одиниця результату — алерт, який закривається сам після виправлення коду, а межі — хвилини Actions і ліцензія для приватних репозиторіїв.
• Можу назвати всі ланки, через які знахідка стає червоним білдом: класифікація в конфізі (типово WARN, у FAIL чи IGNORE переводить рішення по кожному правилу з файлу, згенерованого параметром -g; прапорець -I знімає падіння на попередженнях), перемикач fail_action в обгортці GitHub-дії, статус перевірки як required check — і четверта, мовчазна: інструмент, який не відпрацював.
• Памʼятаю, що порожній звіт неоднозначний за побудовою (чистий код і невідпрацьований інструмент виглядають однаково), а відомий борг виносять у progress-файл із позначкою IN-PROGRESS, а не в IGNORE, щоб у звіті було видно саме нові знахідки.
• Не читаю червоний аудит залежностей як «зʼявилася нова вразливість»: мінімальний рівень для ненульового коду виходу задається конфігом, а сам ненульовий код приходить навіть тоді, коли виправлення вже випущене, просто політика свіжості не пустила пропатчену версію — і памʼятаю, що порогу severity канон не встановлює взагалі, він дає лише механіку.