HTTPS, TLS і безпека

Чим HTTPS відрізняється від HTTP?

HTTPS — це той самий HTTP, але «загорнутий» у криптографічний шар TLS: спершу встановлюється захищений канал, і вже всередині нього ходить звичний HTTP-трафік. HTTP передає запити й відповіді відкритим текстом, і будь-який посередник на шляху — роутер, провайдер, балансувальник — читає їх як листівку. HTTPS додає три речі: шифрування, контроль цілісності й автентифікацію сервера через сертифікат. Порти за замовчуванням різні: 80 для HTTP і 443 для HTTPS. Браузер позначає http:// як «Not secure», а багато сайтів автоматично редиректять на HTTPS. Для автотестів це означає, що жорстко зашитий http:// у базовому URL — потенційне джерело сюрпризів: редиректи, mixed content, HSTS.

Які гарантії дає TLS?

Три різні гарантії, які закривають різні атаки: конфіденційність, цілісність і автентифікацію сервера. Конфіденційність — дані шифруються симетричним алгоритмом (наприклад, AES), і посередник бачить лише беззмістовний набір байтів. Цілісність — підміну навіть одного байта в дорозі буде виявлено, перевірка не збіжиться і з'єднання розірветься; це забезпечує автентифіковане шифрування (AEAD). Автентифікація сервера — сертифікат доводить, що клієнт говорить саме з app.example.com, а не з тим, хто ним прикинувся. Важливий нюанс: за замовчуванням TLS автентифікує лише сервер, клієнт лишається анонімним, доки не увійде через логін чи токен уже всередині захищеного каналу. Плутати ці гарантії — типова помилка на співбесіді: саме по собі шифрування без автентифікації від MITM не рятує.

Що таке сертифікат і хто його видає?

Сертифікат — це файл формату X.509, який пов'язує доменне ім'я з відкритим ключем сервера. Він містить домени, для яких дійсний (поле SAN), відкритий ключ, видавця (issuer), строк дії та цифровий підпис центру сертифікації. Видає його центр сертифікації (Certificate Authority, CA) — організація, якій браузери й ОС довіряють за замовчуванням: Let's Encrypt, DigiCert, Sectigo. Довіра будується ланцюжком: Root CA підписує Intermediate CA, той — leaf-сертифікат сервера, а кореневі сертифікати вшиті у сховище довіри операційної системи та браузера. Браузер перевіряє підписи вгору по ланцюгу, а також збіг домену з SAN, строк дії та чи не відкликано сертифікат. Якщо будь-яка перевірка провалюється — користувач бачить повноекранну помилку замість сайту.

Уранці всі UI-тести на staging масово впали. З чого почнеш діагностику?

Перш ніж лізти в код — відкрити середовище руками й глянути на значок біля адресного рядка: масове падіння вранці — класичний симптом сертифіката, який протух уночі. Chrome у такому разі покаже NET::ERR_CERT_DATE_INVALID. Інші часті помилки сертифіката: NET::ERR_CERT_COMMON_NAME_INVALID — домен не збігається з SAN, NET::ERR_CERT_AUTHORITY_INVALID — підпис невідомого CA, найчастіше self-signed. Логіка проста: якщо впало все й одночасно, причина радше в середовищі, ніж у тестах, і хвилина ручної перевірки економить години розбору логів. На проді з цього ж робиться висновок: корисно мати окремий тест, який перевіряє, що сертифікат валідний і не близький до прострочення.

Що таке self-signed сертифікат і як з ним працювати в автотестах?

Self-signed — це сертифікат, який підписав сам себе, без довіреного CA; браузер йому не довіряє й показує NET::ERR_CERT_AUTHORITY_INVALID. На проді так не роблять, а на dev/staging це нормально — публічний сертифікат для внутрішнього стенду часто недоцільний. Вручну попередження обходять через «Advanced → Proceed», але автотесту потрібні прапорці: у Playwright — опція контексту ignoreHTTPSErrors: true, у Selenium — acceptInsecureCerts, у curl — -k/--insecure. Компроміс треба усвідомлювати: вимкнена перевірка робить тест сліпим до реального MITM і помилок конфігурації сертифіката. Тому прапорець вмикають лише для середовищ, де це очікувано, а не глобально «щоб не заважало». Кращий варіант, де можливо, — додати кореневий сертифікат внутрішнього CA у сховище довіри агента CI: ланцюг стане валідним по-справжньому, і перевірку вимикати не доведеться.

Що таке HSTS і як він може вплинути на автотести?

HSTS (Strict-Transport-Security) — заголовок, який змушує браузер надалі ходити на домен тільки через HTTPS, навіть якщо користувач набрав http:// вручну. Браузер приймає цей заголовок лише з HTTPS-відповіді — надісланий по відкритому HTTP, він ігнорується, тому його віддають уже після редиректу на захищене з'єднання. Коли політику збережено, наступний перехід http→https браузер робить внутрішньо, ще до будь-якого мережевого запиту — у DevTools Chrome це видно як «307 Internal Redirect», який насправді не йде на сервер. Для тестів наслідок конкретний: якщо в базовому URL зашито http://, а домен уже під HSTS, браузер сам перепише схему ще до першого запиту, і перевірки редиректу поводитимуться не так, як очікувалося. Тому перевіряти треба фактичну схему в отриманій відповіді, а не те, що набрали.

Що таке mixed content і чому через нього тест «не бачить елемент»?

Mixed content — це коли сторінка завантажена по HTTPS, але тягне підресурси по HTTP: значок обіцяє захист, а частина трафіку йде відкрито й може бути підмінена. Браузери розрізняють пасивний (картинки, відео, аудіо — їх автоматично підвищують до https, а без HTTPS-версії блокують) і активний (скрипти, стилі, iframe, fetch/XHR — блокується за замовчуванням, бо ці ресурси керують сторінкою). Для AQA це часте джерело flaky-падінь: тест не бачить елемент, бо скрипт, який його малює, заблоковано як active mixed content, — а в консолі при цьому лежить явне попередження «Mixed Content: … This request has been blocked». Тому при діагностиці «елемент не з'явився» варто одразу читати консоль браузера — у Playwright її слухають через подію console. Корінь проблеми зазвичай — жорстко зашитий http:// у конфізі середовища або протокол-залежне посилання, яке зламалося після переїзду стенда на HTTPS.

Які атрибути безпеки кукі ти знаєш і що кожен дає?

Три ключові: HttpOnly, Secure і SameSite. HttpOnly робить кукі недоступним із JavaScript — document.cookie його не бачить, що розриває головний вектор XSS: навіть якщо чужий скрипт виконався, токен сесії він не прочитає. Secure дозволяє надсилати кукі тільки по HTTPS, тож воно не витече випадковим відкритим запитом. SameSite (Lax/Strict) обмежує надсилання кукі при міжсайтових запитах і захищає від CSRF; SameSite=None дозволяє крос-сайт, але браузер тоді вимагає ще й Secure. Нюанс із дефолтом: Chromium-браузери трактують кукі без атрибута як Lax, а Firefox і Safari до такого дефолту не перейшли, тому атрибут краще задавати явно. Для автотестів прямий наслідок: HttpOnly-кукі не читається через document.cookie — це не баг, читати й підставляти його треба через API контексту браузера (context.cookies()), а чистити стан — через context.clearCookies() чи storageState, бо очищення document.cookie таке кукі не прибере.

Що таке XSS і як його тестувати?

XSS (cross-site scripting) — впровадження чужого JavaScript у сторінку, яку бачать інші користувачі; корінь один — дані користувача потрапляють у HTML без екранування, і браузер виконує їх як код. Три типи: stored — payload зберігається на сервері й показується всім (коментар зі <script>), reflected — payload у параметрі запиту вертається у відповіді (шкідливе посилання), DOM-based — уразливість у клієнтському JS без участі сервера (типу innerHTML = location.hash). Наслідки — крадіжка сесії, дії від імені жертви, підміна вмісту. Захист: екранування виводу, санітизація вводу, фреймворки на кшталт React/Angular, які екранують за замовчуванням, і CSP як другий рубіж; небезпечні місця — innerHTML, document.write, dangerouslySetInnerHTML. Для тестувальника це негативні кейси: ввести у поле <img src=x onerror=alert(1)> чи "><script>… і перевірити, що рядок відрендерився як текст (<script> у розмітці), а не виконався — тобто в DOM не з'явився новий виконаний скрипт.

Чим CSRF відрізняється від XSS і як від нього захищаються?

CSRF (cross-site request forgery) експлуатує те, що браузер автоматично додає кукі до кожного запиту на домен: жертва залогінена в bank.example, відкриває сайт зловмисника, а той тихо шле форму на bank.example/transfer — браузер прикріплює кукі сесії, і сервер вважає дію легітимною. Ключова відмінність від XSS: зловмисник не читає відповідь і не краде дані напряму — він змушує браузер жертви виконати дію її ж правами. Захисти: CSRF-токен (непередбачуване значення, яке сервер кладе у форму й перевіряє при сабміті — чужий сайт його не знає), атрибут кукі SameSite і перевірка заголовків Origin/Referer на сервері. Для AQA це часте джерело болю в API-тестах в обхід UI: сервер відповідає 403, бо не передано свіжий токен. Правильний шлях — спершу отримати токен зі сторінки чи спеціального ендпоінта й підставити в запит, а не хардкодити.

Що таке SQL-ін'єкція і який захист вважається надійним?

SQL-injection — впровадження SQL-коду через дані, які потрапляють у запит до бази без параметризації, класично — через конкатенацію рядка. Якщо в input передати ' OR '1'='1, умова стане завжди істинною і запит поверне всіх користувачів; ще гірше — '; DROP TABLE users; --. Надійний захист один — параметризовані запити (prepared statements), де дані передаються окремо від тексту запиту й ніколи не інтерпретуються як код. AQA дотичний через негативні кейси: підставити у поля характерні payload'и (' OR 1=1 --, лапки, крапку з комою) і перевірити, що застосунок повертає коректну помилку валідації або порожній результат, а не чужі дані чи 500. Важливе застереження: робити це можна виключно на своїх тестових середовищах і ніколи — на чужих чи продакшн-системах без дозволу.

Чому секрети не можна класти у фронтенд-код і в query-рядок, навіть по HTTPS?

Фронтенд-код повністю видимий користувачеві: будь-хто відкриває DevTools → Sources і читає весь JavaScript, включно з «захованим» у змінну чи мініфікованим, — тому будь-який ключ у клієнтському коді вже не секрет. Фронтенду можна давати лише публічні ідентифікатори, які й призначені бути відкритими. Query-рядок по HTTPS справді зашифрований у дорозі, але повний URL із параметрами пишеться в логи сервера, проксі та балансувальників, зберігається в історії браузера, може протекти в заголовку Referer при переході на інший сайт і потрапляє в аналітику. Тому секрети передають у заголовках (найчастіше Authorization: Bearer …) або в тілі POST. Для автотестів правило те саме: токени в CI живуть у секретах середовища й підставляються через змінні оточення, а не хардкодяться в репозиторій, а логи тестів варто фільтрувати, щоб токен не осів у публічному звіті білда.

Що таке CSP і як суворий CSP впливає на автотести?

CSP (Content-Security-Policy) — заголовок відповіді, який каже браузеру, з яких джерел дозволено вантажити ресурси й виконувати код; це головний рубіж проти XSS — навіть впроваджений скрипт не виконається, якщо його джерело не в білому списку. Основні директиви: default-src (дефолт для решти), script-src, style-src, img-src, connect-src (fetch/XHR/WebSocket), frame-src. Є режим тільки-звіт — Content-Security-Policy-Report-Only, який нічого не блокує, а лише шле звіти про порушення: зручно ввімкнути перед бойовим запуском політики. Для автотестів практика така: сувора CSP без 'unsafe-inline' заблокує інжект допоміжного <script> чи inline-обробника, і в консолі з'явиться порушення. При цьому page.evaluate у Playwright здебільшого проходить — код їде через Chrome DevTools Protocol, а не вставляється тегом, тож script-src його зазвичай не зачіпає; виняток — дуже сувора політика без 'unsafe-eval', під якою можуть падати eval-залежні механізми на кшталт page.waitForFunction. Для addScriptTag та inline-обробників Playwright має окрему опцію bypassCSP, а на проді корисно мати зворотну перевірку — що CSP присутній і список джерел не «поплив» після релізу.

Як працює TLS-рукостискання і що таке forward secrecy?

Ключова ідея: асиметрична криптографія працює лише на старті, щоб сторони узгодили спільний симетричний ключ сесії, а далі весь трафік шифрується швидким симетричним алгоритмом. У TLS 1.3 ключ сесії виводиться через ефемерний обмін Діффі — Гелмана (ECDHE), а приватний ключ із сертифіката використовується для підпису рукостискання — тобто для автентифікації сервера, а не для передавання самого ключа. Клієнт шле ClientHello з підтримуваними шифрами і своєю частиною ECDHE, сервер відповідає ServerHello, сертифікатом і підписом; клієнт перевіряє ланцюг довіри й підпис — і обидві сторони виводять спільний ключ. Наслідок такої схеми — пряма секретність (forward secrecy): навіть якщо приватний ключ сервера пізніше витече, раніше записаний трафік ним розшифрувати не вдасться. Актуальні версії — TLS 1.2 і TLS 1.3 (RFC 8446); SSL 2.0/3.0 і TLS 1.0/1.1 вважаються небезпечними й вимкнені. Окремий випадок — mutual TLS (mTLS), де сертифікат пред'являє і клієнт: застосовується у зв'язках «сервіс до сервісу» і в тестах зазвичай потребує окремого налаштування клієнтського сертифіката.

Що з HTTPS-трафіку все одно бачить посередник?

TLS шифрує тіло й заголовки HTTP, але не приховує сам факт з'єднання: посередник бачить IP-адресу сервера і — через SNI (Server Name Indication) у рукостисканні — доменне ім'я, до якого ви йдете. Він не бачить конкретний шлях, параметри запиту, кукі й тіло — тобто «що ви відкрили на сайті» приховано, а «на який сайт пішли» здебільшого ні. Це і є коректна відповідь сеньйорського рівня: HTTPS захищає вміст, а не метадані з'єднання. Розширення ECH (Encrypted Client Hello) шифрує й доменне ім'я в рукостисканні; свіжі версії Chrome, Firefox і Safari вмикають його за замовчуванням за наявності DNS-over-HTTPS, але працює воно лише там, де ECH підтримує сам сервер чи CDN, — покриття поки невелике, тож на практиці домен здебільшого все ще видно. Практичний висновок: чи працює ECH у твоєму середовищі, залежить від браузера, CDN і DNS-резолвера — перевіряти треба на цільовій конфігурації, а не покладатися на «має бути».

Як працюють Charles, mitmproxy чи Burp, якщо HTTPS захищає від MITM?

Це, по суті, легальний MITM — і те, що для нього потрібен окремий крок, якраз доводить, що захист працює. HTTPS протидіє MITM двома механізмами одночасно: шифрування робить пасивне підслуховування марним, а автентифікація сервера вимагає від зловмисника валідного сертифіката на потрібний домен від довіреного CA — отримати такий без контролю над доменом він не може, а self-signed браузер відхилить із попередженням. Проксі-інструменти обходять це чесно: встановлюють свій кореневий сертифікат у сховище довіри вашої машини, після чого браузер довіряє сертифікатам, які проксі генерує на льоту для кожного домену. Без цього кроку браузер підняв би тривогу — саме тому попередження про сертифікат, яке хочеться «просто проклацати», і є моментом, коли HTTPS ловить потенційну атаку. В автотестах та сама механіка звужується до page.route у Playwright: ви навмисне стаєте посередником у власному ізольованому оточенні, щоб мокати API, імітувати помилки й таймаути та прибрати мережеву нестабільність — одну з головних причин flakiness. Різниця з атакою лише в намірі й у тому, що це ваше контрольоване середовище.

Три кейси, де TLS і безпека вирішують, зелений тест чи «падає без причини»: обхід self-signed сертифіката на staging плюс охоронний тест валідності серта на проді, діагностика flaky-падіння через заблокований active mixed content / CSP, і читання HttpOnly-кукі сесії з обходом CSRF-токена в API-тесті. Скрізь — що дивитися і чому.

Кейс 1. Self-signed на staging: обійти, але не осліпнути на проді

На внутрішньому стенді сертифікат підписаний сам собою, тож браузер кидає NET::ERR_CERT_AUTHORITY_INVALID, і тест не доходить навіть до логіну. Руками рятує «Advanced → Proceed», але в автотесті так не клікнеш — вмикаєш прапорець «не перевіряй серт»:

// playwright.config.ts — тільки для dev/staging-проєкту
export default defineConfig({
  projects: [
    {
      name: 'staging',
      use: { baseURL: 'https://staging.internal', ignoreHTTPSErrors: true },
    },
  ],
});

Компроміс: із ignoreHTTPSErrors: true тест став сліпим до реального MITM і до кривої конфігурації серта. Тому на проді роблять дзеркальний, охоронний тест — що сертифікат валідний і не близький до прострочення. Найпростіше — openssl у CI:

# лишається < 15 днів до прострочення → нехай CI впаде
echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null \
  | openssl x509 -noout -checkend 1296000

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

• ignoreHTTPSErrors — точково, не глобально. Вмикай лише в проєкті/середовищі, де self-signed справді очікуваний. Глобальне «щоб не заважало» ховає справжні помилки серта на проді.
• -servername в s_client обовʼязковий. Без нього не передається SNI, і сервер за одним IP може віддати не той серт (дефолтний), — перевіриш чужий ланцюг і зробиш хибний висновок.
• -checkend <секунди> — це і є охоронна асерція. Команда виходить із ненульовим кодом, якщо серт спливе раніше, ніж за вказаний інтервал. Прострочений уночі серт staging — реальна причина масового «падіння» тестів вранці; такий тест ловить це до релізу, а не після.
• Ще краще за прапорець — довіра по-справжньому. Якщо додати кореневий серт внутрішнього CA у trust store агента CI, ланцюг стає валідним, і ignoreHTTPSErrors не потрібен узагалі.

Кейс 2. «Елемент не зʼявився» — а це заблокований скрипт (mixed content / CSP)

Тест raptom не бачить кнопку, локатор таймаутить, скрін порожній. Перша інтуїція — «повільна сторінка, додам wait». Насправді скрипт, який малює той елемент, браузер заблокував: або як active mixed content (http://-скрипт на HTTPS-сторінці), або як порушення CSP. І там, і там доказ лежить у консолі, а не в DOM. Тому в діагностиці спершу слухай console, а не нарощуй таймаути:

import { test, expect } from '@playwright/test';

test('форма рендериться, а не глушиться політикою', async ({ page }) => {
  const problems: string[] = [];
  page.on('console', (msg) => {
    const t = msg.text();
    if (/Mixed Content|Content Security Policy|Refused to/i.test(t)) problems.push(t);
  });

  await page.goto('https://app.example.com/checkout');

  // спершу ПРИЧИНА (заблоковані ресурси), і лише потім наслідок (кнопка) —
  // інакше toBeVisible впаде першим голим таймаутом і причину ти не побачиш
  expect(problems, problems.join('\n')).toHaveLength(0);
  await expect(page.getByRole('button', { name: 'Pay' })).toBeVisible();
});

Типові повідомлення, які ловить фільтр:

Mixed Content: The page at 'https://app.example.com/' was loaded over HTTPS,
but requested an insecure script 'http://cdn.example.com/app.js'.
This request has been blocked; the content must be served over HTTPS.

Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self'".

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

• Active vs passive — різна поведінка. Скрипти, стилі, iframe, fetch/XHR браузер блокує за замовчуванням (керують сторінкою). Картинки/відео/аудіо він тихо підвищує з http до https; тому «зникла кнопка» — це майже завжди active-контент, а не картинка.
• Корінь — зашитий http://. Часто винен протокол-залежний URL у конфізі середовища, який зламався після переїзду стенду на HTTPS. Лікуєш конфіг, а не тест.
• page.evaluate під CSP здебільшого живе, addScriptTag — ні. Код evaluate їде через CDP і виконується в контексті сторінки, тож script-src його зазвичай не чіпає. А спроба вставити <script> чи inline-обробник під суворою CSP не спрацює — для таких випадків у Playwright є bypassCSP: true. Виняток — дуже сувора CSP без 'unsafe-eval': page.waitForFunction спирається на eval-подібні конструкції й може падати.
• Корисний і зворотний тест. Асерти, що CSP взагалі присутній і список джерел не «поплив» після релізу — щоб ніхто не дописав 'unsafe-inline' заради швидкого фіксу.

Кейс 3. HttpOnly-кукі й CSRF-токен: чому document.cookie тут безсилий

Треба перевірити стан сесії або піти в API в обхід UI. Спокуса — прочитати токен через document.cookie. Але серверна кукі з HttpOnly для JS сторінки невидима — і це не баг тесту, так задумано (саме HttpOnly розриває головний вектор XSS). Читати таку кукі треба через API контексту браузера:

import { test, expect } from '@playwright/test';

test('кукі сесії HttpOnly і Secure, читається лише через контекст', async ({ page, context }) => {
  await page.goto('https://app.example.com/login');
  // ... виконуємо логін ...

  // document.cookie НЕ побачить HttpOnly-кукі — поверне порожньо/без session
  const viaJs = await page.evaluate(() => document.cookie);
  expect(viaJs).not.toContain('session=');

  // правильний шлях — API контексту
  const session = (await context.cookies()).find((c) => c.name === 'session');
  expect(session?.httpOnly).toBe(true);
  expect(session?.secure).toBe(true);
});

Далі — типовий біль API-перевірки в обхід UI: сервер відповість 403, бо чужий сайт (і ваш «голий» запит) не знає свіжого CSRF-токена. Хардкодити токен марно — його треба спершу дістати зі сторінки/ендпоінта, а вже потім підставити:

// 1) забираємо свіжий CSRF-токен зі сторінки (мета-тег або прихований інпут)
const csrf = await page.getAttribute('meta[name="csrf-token"]', 'content');

// 2) підставляємо у стан-змінний запит; кукі сесії поїдуть автоматично з контексту
const res = await page.request.post('https://app.example.com/api/transfer', {
  headers: { 'X-CSRF-Token': csrf ?? '', 'Content-Type': 'application/json' },
  data: { to: 'acc-2', amount: 10 },
});
expect(res.status()).toBe(200);

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

• HttpOnly кукі → тільки context.cookies(). Через document.cookie токен сесії не прочитається ніколи; асерт httpOnly === true / secure === true заразом фіксує, що атрибути безпеки на місці.
• Ізоляція стану теж впирається в це. Очищення document.cookie не прибере HttpOnly-кукі. Між тестами стартуй із чистого контексту або керуй станом через storageState / context.clearCookies().
• 403 на API — часто відсутній/протухлий CSRF-токен, а не зламані права. Токен беруть свіжим перед кожним стан-змінним запитом; підстав старий — і сервер його відхилить.
• SameSite не задавай «за дефолтом». Chromium вважає кукі без атрибута за Lax, а Firefox і Safari — ні. Покладатися на дефолт крихко; у перевірках очікуй саме явно заданий атрибут.

HTTPS, TLS і що воно гарантує

• Можу пояснити різницю HTTP vs HTTPS: HTTPS — той самий HTTP, «загорнутий» у TLS; порт 443 замість 80, шифрування, цілісність, автентифікація сервера через сертифікат.
• Розумію, що TLS шифрує заголовки й тіло, але не приховує факт зʼєднання: посередник бачить IP і — через SNI — домен, але не шлях, параметри, кукі й тіло (домен ховає лише ECH, покриття якого поки мале).
• Можу розвести три гарантії TLS: конфіденційність (симетричне шифрування, AES), цілісність (AEAD виявляє підміну байта), автентифікація сервера (сертифікат) — і що за замовчуванням клієнт лишається анонімним, доки не залогіниться.
• Розумію суть рукостискання: асиметрія працює лише на старті для узгодження симетричного ключа сесії; у TLS 1.3 ключ виводиться через ефемерний ECDHE, звідси forward secrecy — витік приватного ключа не розшифрує раніше записаний трафік; актуальні версії — TLS 1.2/1.3, а SSL 2.0/3.0 і TLS 1.0/1.1 небезпечні й вимкнені.
• Можу пояснити HSTS: браузер приймає заголовок лише з HTTPS-відповіді, далі ходить на домен тільки через https://; наступний http→https він робить внутрішньо (307 Internal Redirect), тому перевіряю фактичну схему у відповіді, а не в набраному URL.

Сертифікати, ланцюг довіри й MITM

• Можу описати сертифікат X.509: домени (поле SAN), відкритий ключ, issuer, строк дії, підпис CA — і що браузери дивляться на SAN, а не на застаріле Common Name.
• Розумію ланцюг довіри: Root CA → Intermediate → leaf; корені вшиті у trust store ОС/браузера, сервер віддає leaf із проміжними, браузер перевіряє підписи вгору до кореня плюс домен, строк і відкликання (OCSP/CRL).
• Знаю типові помилки сертифіката в Chrome: NET::ERR_CERT_DATE_INVALID (прострочений/невірна дата), NET::ERR_CERT_COMMON_NAME_INVALID (домен ≠ SAN), NET::ERR_CERT_AUTHORITY_INVALID (невідомий CA, часто self-signed).
• Розумію, що прострочений сертифікат staging — реальна причина масового «падіння» тестів уранці, тому спершу відкриваю середовище руками й дивлюсь на значок, а не лізу в код.
• Можу пояснити self-signed на dev/staging і обхід у тестах: Playwright ignoreHTTPSErrors, Selenium acceptInsecureCerts, curl -k; усвідомлюю компроміс — це робить тест сліпим до MITM, тож краще додати внутрішній кореневий CA у trust store агента CI.
• Можу пояснити MITM і чому HTTPS протидіє двома механізмами разом (шифрування + автентифікація сервера), і що mitmproxy/Charles/Burp — легальний MITM, який працює лише зі своїм кореневим сертифікатом у trust store; page.route у Playwright — контрольований MITM усередині тесту.

Атаки рівня застосунку

• Можу пояснити XSS як впровадження чужого JS через неекранований ввід і три типи: Stored, Reflected, DOM-based; захист — output encoding, санітизація, фреймворки, CSP; небезпечні місця — innerHTML, document.write, dangerouslySetInnerHTML.
• Розумію, як AQA тестує XSS негативно: ввести <img src=x onerror=alert(1)> чи "><script> і перевірити, що рядок показано як текст (<script>), а не виконано.
• Можу пояснити CSRF і головну відмінність від XSS: зловмисник не читає відповідь, а змушує браузер жертви виконати дію її ж правами, бо кукі шлються автоматично; захист — CSRF-токен, SameSite, перевірка Origin/Referer; знаю, що API-тести в обхід UI ловлять 403, бо треба спершу дістати свіжий токен, а не хардкодити.
• Можу пояснити SQL-injection через конкатенацію (' OR '1'='1, '; DROP TABLE) і єдиний надійний захист — параметризовані запити; знаю, що payloadʼи ганяю лише на своїх середовищах.

Політики браузера, кукі й секрети

• Можу пояснити mixed content: пасивний (картинки — автоматично підвищується до HTTPS або блокується) і активний (скрипти, стилі, iframe, fetch — блокується); це часте джерело flaky-падінь, тому при «елемент не зʼявився» відразу дивлюсь консоль.
• Можу пояснити CSP як заголовок-білий-список джерел і другий рубіж проти XSS; знаю ключові директиви (default-src, script-src, connect-src, frame-src) і режим Content-Security-Policy-Report-Only.
• Розумію взаємодію CSP з Playwright: page.evaluate зазвичай проходить (їде через CDP), але сувора CSP без 'unsafe-eval' може ламати waitForFunction, а addScriptTag/inline під суворою політикою потребують bypassCSP.
• Можу пояснити атрибути кукі: HttpOnly (недоступне з document.cookie, проти крадіжки сесії через XSS), Secure (лише по HTTPS), SameSite (проти CSRF); знаю, що SameSite=None вимагає Secure і що дефолт Lax — лише в Chromium, тож атрибут задаю явно.
• Можу пояснити, чому секретам не місце у фронтенді (весь JS видно в DevTools) і в query (?token=… осідає в логах, історії, Referer, аналітиці) — секрети йдуть у заголовку Authorization чи в тілі POST, а в CI — через змінні оточення.