CORS і політика однакового походження

Що таке походження (origin) і з чого воно складається?

Origin — це трійка «схема + хост + порт»: два URL належать до одного походження лише тоді, коли всі три складові збігаються. Шлях, query-параметри та фрагмент в origin не входять, тож https://app.example.com/dashboard і https://app.example.com/users — одне походження. А от http://app.example.com проти https://app.example.com — уже різні (інша схема), як і https://app.example.com:8443 (інший порт). Важлива деталь: порт за замовчуванням залежить від схеми — 443 для https, 80 для http, тому https://site.com і https://site.com:443 — це одне й те саме походження. Саме від цього визначення відштовхуються і Same-Origin Policy, і CORS.

Чи є app.example.com та api.example.com одним походженням? А localhost:3000 і localhost:4000?

Ні в першому випадку, ні в другому. Піддомен — це інший хост: у app.example.com і api.example.com спільний лише домен другого рівня, а хости різні, отже, походження різні. http://localhost:3000 і http://localhost:4000 відрізняються портом — теж різні походження, і між ними діють усі крос-орідж-правила. Для AQA це щоденна практика: фронт на одному порту, мок-сервер API на іншому — це вже крос-орідж, і добра частина «дивних» помилок у локальних E2E-середовищах береться саме звідси. Тому при незрозумілій мережевій помилці в тесті перше, що варто звірити, — чи справді фронт і бек в очікуваному походженні.

Що таке політика однакового походження (Same-Origin Policy) і навіщо вона потрібна?

SOP — базове правило безпеки браузера: скрипт, завантажений з одного походження, за замовчуванням не може читати дані з іншого походження. Це не заголовок і не налаштування — це вбудована поведінка браузера, яка діє завжди. Класична мотивація: ти залогінений у банку в одній вкладці, а в сусідній відкрив evil.com; без SOP скрипт зловмисника зробив би запит на API банку, браузер автоматично підставив би твої cookie, і скрипт прочитав би баланс та номери рахунків. SOP гарантує, що навіть якщо запит полетить, прочитати відповідь чужому скрипту браузер не дасть. CORS потім з'явився як контрольований спосіб послабити це правило з боку сервера.

Що саме обмежує SOP, а що — ні?

Ключова ідея: SOP обмежує читання даних скриптом, а не саме звернення до ресурсу. Блокується: читання відповіді на fetch/XHR до чужого походження (без CORS), доступ до DOM чужого iframe через contentDocument, читання cookie та localStorage/sessionStorage іншого походження. Не блокується: вбудовування чужого зображення через img, підключення чужого скрипта через script, відправлення форми на чуже походження. Тобто браузер, можливо, і надішле запит, і навіть покаже картинку — але витягнути дані назад у скрипт не дасть. Розуміння цієї межі «читати не можна, вбудовувати/надсилати можна» — фундамент, з якого виводяться і CORS, і CSRF.

Чому теги img і script історично не блокуються SOP?

Бо SOP забороняє читати чужий вміст, але дозволяє його вбудовувати (embed) — витоку даних при вбудовуванні немає. Браузер завантажить img і намалює картинку, але JS не зможе прочитати її пікселі: спроба зчитати чуже зображення з canvas «забруднює» (taint) його, і getImageData/toDataURL кидають помилку безпеки. Так само чужий script виконається, але прочитати його вихідний текст як рядок скрипт-хост не зможе. Історично цю «дірку» використовував JSONP: сервер повертав виклик функції myCallback(...) замість чистого JSON, і його підключали через script, обходячи SOP ще до появи CORS — сьогодні прийом вважають застарілим і небезпечним. Зворотний бік дозволеного вбудовування — атака CSRF: форму чи img можна націлити на чуже походження, і браузер підставить cookie.

Що таке CORS і яку проблему він вирішує?

CORS (Cross-Origin Resource Sharing) — механізм, яким сервер явно дозволяє певним чужим походженням читати свої відповіді. Проблема в тому, що чистий SOP занадто суворий: сучасний застосунок на https://app.example.com майже завжди ходить по дані на окремий бекенд https://api.example.com, а це інше походження. Працює CORS через HTTP-заголовки: сервер додає у відповідь Access-Control-Allow-*, а браузер їх читає й вирішує, чи віддавати відповідь скрипту. Важливо формулювати саме так: CORS не «вимикає» безпеку, а дає серверу контрольований спосіб сказати браузеру «цьому походженню я довіряю». Примусово застосовує політику завжди браузер, сервер лише повідомляє її.

Як працює заголовок Access-Control-Allow-Origin?

Це головний CORS-заголовок відповіді: він каже браузеру, якому походженню дозволено читати цю відповідь. Механіка: браузер сам додає до крос-орідж-запиту заголовок Origin з походженням сторінки; сервер відповідає, і якщо Access-Control-Allow-Origin збігається з цим origin (або дорівнює *), браузер віддає відповідь скрипту. Якщо заголовка немає або значення інше — доступ блокується, і в консолі з'являється помилка на кшталт No 'Access-Control-Allow-Origin' header is present. Значення * означає «будь-кому», але воно не працює разом із credentials. Фронтенд не може «домалювати» собі цей заголовок — його джерело істини завжди сервер.

Які крос-орідж-запити браузер вважає «простими», а які потребують preflight?

Простий запит браузер шле одразу, якщо виконуються всі умови: метод GET, HEAD або POST; заголовки лише з безпечного списку (Accept, Accept-Language, Content-Language, Content-Type); а Content-Type — лише text/plain, multipart/form-data або application/x-www-form-urlencoded. Щойно запит виходить за ці рамки, браузер спершу шле preflight. На практиці майже будь-який реальний API-запит потрапляє під preflight: JSON із Content-Type: application/json, токен в Authorization, методи PUT/PATCH/DELETE — кожного з цих пунктів окремо вже достатньо. Тому в Network на один логічний запит часто видно два записи: OPTIONS і основний.

Що таке preflight-запит і як він виглядає?

Preflight — це попередній запит методом OPTIONS, який браузер надсилає сам, автоматично, ще до справжнього запиту: «чи можна мені зробити запит із цим методом і цими заголовками?». У ньому браузер передає Origin, Access-Control-Request-Method і Access-Control-Request-Headers — опис того, що він збирається зробити. Сервер має відповісти статусом 2xx із Access-Control-Allow-Origin, Access-Control-Allow-Methods та Access-Control-Allow-Headers; лише тоді полетить основний запит. Будь-який інший код — редирект, 401, 404, 500 — валить перевірку, і основний запит браузер навіть не надішле. Результат preflight кешується на час з Access-Control-Max-Age, щоб не питати щоразу (браузери обмежують значення згори: Firefox — до 86400 с, Chromium — до 7200 с).

Чому не можна вішати перевірку авторизації на маршрут OPTIONS?

Бо preflight за специфікацією йде без credentials: cookie на сам OPTIONS не надсилаються, тіла він теж не містить. Якщо на маршруті стоїть перевірка авторизації, вона завалить preflight (наприклад, віддасть 401), а не-2xx на OPTIONS означає, що браузер навіть не надішле основний запит. У консолі це виглядає як Response to preflight request doesn't pass access control check — і команда може довго шукати проблему в токенах основного запиту, хоча падає службовий OPTIONS. Це типова пастка бекенд-конфігурації, яку варто впізнавати з одного погляду на вкладку Network: дивись статус саме OPTIONS-запису, а не основного.

Чому CORS-помилка є в браузері, а в Postman чи curl «усе працює»?

Бо CORS перевіряє браузер, а не сервер: заголовки Access-Control-Allow-* — це інструкція для браузера, як вчинити з відповіддю. Postman, curl, HTTP-клієнти в коді, APIRequestContext у Playwright — не браузери: вони не реалізують SOP і просто ігнорують CORS-заголовки — отримали відповідь і віддали її повністю. Тому теза «у Postman працює, значить бекенд правий» хибна: Postman «працює» завжди, бо йому байдуже до CORS, і це нічого не каже про те, чи віддасть браузер відповідь скрипту. Практичний висновок для тестів: браузерну CORS-помилку відтворюй у браузері (E2E), а якщо API треба перевірити ізольовано від CORS — бий по ньому з HTTP-клієнта.

Чи означає повідомлення «blocked by CORS policy», що запит не дійшов до сервера?

Ні, не обов'язково — і це відрізняє того, хто розуміє механізм, від того, хто зазубрив. Для простого запиту сервер виконує його повністю: запит доходить, база оновлюється, всі побічні ефекти стаються — браузер лише не дає скрипту прочитати відповідь. Для запиту з preflight інакше: якщо OPTIONS не дав дозволу, основний запит браузер не надішле зовсім. Тобто «CORS заблокував» для простого POST цілком може означати «запит дійшов і спрацював, але відповідь тобі не показали». Для автотестів це прямий ризик: не можна покладатися на «браузер же заблокував» як на захист від зміни даних — стан прибирай явно, інакше отримаєш «брудні» дані між тестами.

Фронтендер каже «CORS-помилка, винен бекенд», бекендер — «у curl 200, все ок». Хто лагодить?

Правило за замовчуванням: CORS лагодиться на бекенді, бо заголовки Access-Control-Allow-* віддає сервер, а «в curl 200» нічого не доводить — curl не перевіряє CORS. Якщо в консолі No 'Access-Control-Allow-Origin' header is present, ACAO з іншим походженням, метод не перелічений в Allow-Methods або OPTIONS повертає не-2xx — усе це фіксить бекенд. Винятки з боку фронта два: він забув credentials: 'include' (запит іде без cookie), або сам додає зайвий заголовок, який тягне непотрібний preflight. Окремий обхід — проксі на dev-сервері (Vite, webpack, nginx), який робить запит однопохідним для браузера, але це не «фікс CORS». Як AQA у баг-репорті замість «CORS не працює» давай факти: точний текст помилки з консолі, значення Origin у запиті, наявні заголовки Access-Control-* у відповіді й чи був preflight OPTIONS — це одразу спрямовує фікс і економить раунд «а покажи в Postman».

Фронт шле запит із credentials: 'include', сервер відповідає Access-Control-Allow-Origin: *. Спрацює?

Ні, браузер заблокує відповідь, попри те що зірочка нібито «дозволяє всім». Коли запит іде з credentials (cookie, HTTP-автентифікація, клієнтські TLS-сертифікати), вимоги суворішають: в Access-Control-Allow-Origin не можна * — лише конкретне походження; обов'язковий Access-Control-Allow-Credentials: true; а * в Access-Control-Allow-Headers/-Methods перестає діяти як «усі» — треба перелічувати явно. Логіка проста: якщо сервер віддає приватні дані під конкретну сесію, він має назвати конкретне довірене походження, а не «будь-кого». Для E2E це часте пояснення «розлогінювання» посеред тесту на локальному стенді, коли фронт і API на різних портах: сесія не доходить через недоналаштований Access-Control-Allow-Credentials, а не через баг застосунку.

Бекенд шле заголовок X-Total-Count, але скрипт через response.headers.get(...) отримує null. Чому?

Бо навіть коли браузер віддав скрипту тіло крос-орідж-відповіді, за замовчуванням читати можна лише безпечний набір заголовків відповіді — їх рівно сім: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma. Кастомні заголовки на кшталт X-Total-Count чи X-Request-Id скрипт не побачить, доки сервер явно не перелічить їх у Access-Control-Expose-Headers. У Network при цьому заголовок видно — він реально приходить, просто браузер не віддає його скрипту. Це прямий практичний гачок для тестів: якщо перевірка читає X-Total-Count із крос-орідж-відповіді й падає на «undefined», причина часто не в бекенді, який заголовок таки шле, а у відсутньому Access-Control-Expose-Headers.

Чим CORS відрізняється від CSRF?

Це різні проблеми, які часто плутають: CORS — про читання відповіді, CSRF — про небажану дію. CSRF (Cross-Site Request Forgery) експлуатує те, що SOP дозволяє: форму чи img можна націлити на чуже походження, браузер підставить cookie, і сервер виконає дію (наприклад, POST на переказ грошей) — навіть якщо прочитати відповідь зловмисник не зможе. CORS цю атаку не зупиняє: для простого запиту сервер виконує його повністю, браузер блокує лише читання відповіді скриптом. Тому «у нас налаштований CORS» — не відповідь на питання про захист від CSRF: це різні механізми з різними цілями. Сильний кандидат формулює межу так: CORS вирішує, кому можна читати дані, а захист від CSRF — чи справді дію ініціював сам користувач.

Коли браузер надсилає Origin: null і чим небезпечно приймати його за «своє» походження?

Origin: null браузер шле, зокрема, для сторінок із пісочного (sandboxed) iframe без дозволу allow-same-origin, а також у деяких інших контекстах. Небезпека в тому, що null — це не конкретне довірене походження, а маркер «походження немає»: сервер, який звіряє Origin за білим списком і механічно додає туди null, фактично відчиняє двері всім контекстам, що його генерують. Тому сервер має свідомо вирішити, як чинити з null, а не приймати його за «своє». На співбесіді це питання перевіряє, чи розумієш ти, що значення Origin не завжди «нормальний URL», і чи бачив ти цей кейс у реальному трафіку.

Сервер віддзеркалює дозволений Origin із білого списку назад у відповідь. Який заголовок обов'язково додати і що буде без нього?

Обов'язково Vary: Origin. Віддзеркалення (echo) — часта практика: замість хардкоду одного значення сервер перевіряє вхідний Origin за білим списком і повертає дозволене походження в Access-Control-Allow-Origin. Але тоді та сама URL-адреса віддає різні відповіді різним походженням, і без Vary: Origin кеш (проксі чи CDN) може віддати одному походженню відповідь, закешовану для іншого — з чужим ACAO. Результат — плаваюча (флакова) CORS-помилка, яку дуже важко зловити: усе працює, потім раптово блокується, потім знову працює залежно від того, чия відповідь лежить у кеші. Для AQA це один із небагатьох випадків, коли CORS-помилка справді нестабільна за своєю природою, а не через тест.

Як CORS і preflight впливають на мокання мережі та очікування в E2E-тестах?

Три головні наслідки. Перше — мокання: коли перехоплюєш крос-орідж-запити (page.route у Playwright, перехоплення в Cypress), браузер може спершу вистрілити OPTIONS; якщо мок не обробляє його окремо або не повертає у fulfill потрібних Access-Control-Allow-*, справжній запит не піде, і тест впаде з CORS-помилкою, «якої не мало бути» — тож у мок-відповідь додавай і CORS-заголовки. Друге — waits: один логічний запит дає два записи в мережі (OPTIONS плюс основний), тож очікування прив'язуй саме до основного методу та URL, а не до службового OPTIONS. Третє — API-контекст: request/APIRequestContext у Playwright — це HTTP-клієнт без SOP, зручний для підготовки стану (seeding) в обхід CORS, але браузерну CORS-помилку ним не відтвориш — для неї потрібен реальний браузерний контекст.

Три кейси, де CORS вирішує, зелений тест чи флак: як прочитати CORS-помилку в консолі й Network та відрізнити preflight від справжнього запиту, як мок у Playwright валить тест «неіснуючою» CORS-помилкою, бо не обробив OPTIONS, і чому та сама відповідь проходить у APIRequestContext, але не відтворює браузерний баг. Скрізь — що дивитися і чому.

Кейс 1. Читаємо CORS-помилку в консолі та Network: хто винен

Фронтендер приніс скриншот консолі й каже «винен бекенд». Перш ніж заводити баг, тестувальник має зібрати факти, а не переказати текст помилки. Типова помилка виглядає так:

Access to fetch at 'https://api.example.com/orders' from origin
'https://app.example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

У вкладці Network той самий логічний запит із JSON-тілом та токеном дає два записи — спершу preflight, потім основний:

OPTIONS /orders HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://other.example.com

Зверни увагу: це відповідь на preflight, і заголовок Access-Control-Allow-Origin у ній є — просто з чужим origin. Тому реальний текст у консолі буде про невідповідність значення (...that is not equal to the supplied origin), а варіант No '...' header is present зʼявляється, коли заголовка немає взагалі. Обидва читаються однаково: звір Origin запиту зі значенням у відповіді.

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

• Спочатку — який саме запит підсвічено червоним. Якщо валить OPTIONS, основний POST навіть не полетить, і текст буде Response to preflight request doesn't pass access control check. Якщо валить основний запит — preflight пройшов, а не збігся Access-Control-Allow-Origin на реальній відповіді. Це два різні діагнози на одному екрані.
• Звірити Origin запиту зі значенням Access-Control-Allow-Origin відповіді. У прикладі сервер віддав https://other.example.com, а сторінка живе на https://app.example.com — не збігається, браузер блокує читання. Причина на бекенді: не дозволив саме це походження.
• No 'Access-Control-Allow-Origin' header is present майже завжди бекенд. Фронт не може «домалювати» собі цей заголовок — браузер бере його виключно з відповіді сервера.
• У баг-репорт — факти, не «CORS не працює». Точний текст із консолі, значення Origin у запиті, наявні/відсутні Access-Control-* у відповіді та чи був preflight OPTIONS. Це відразу спрямовує фікс і економить раунд «а покажи в Postman».

Кейс 2. Мок у Playwright валить тест CORS-помилкою, «якої не мало бути»

Найпідступніший клас у перехопленні мережі: мокаєш крос-орідж-POST, а тест падає з CORS-помилкою, хоч жодного реального сервера в грі немає. Причина — page.route перехопив основний запит, але браузер спершу вистрілив preflight, і мок його не обробив.

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

test('мок крос-орідж-POST має обробити і preflight', async ({ page }) => {
  await page.route('https://api.example.com/orders', async (route) => {
    const req = route.request();

    // preflight: віддати дозвіл, інакше основний запит не піде
    if (req.method() === 'OPTIONS') {
      return route.fulfill({
        status: 204,
        headers: {
          'Access-Control-Allow-Origin': 'https://app.example.com',
          'Access-Control-Allow-Methods': 'POST, OPTIONS',
          'Access-Control-Allow-Headers': 'authorization, content-type',
        },
      });
    }

    // основна відповідь теж потребує CORS-заголовка
    return route.fulfill({
      status: 201,
      contentType: 'application/json',
      headers: { 'Access-Control-Allow-Origin': 'https://app.example.com' },
      body: JSON.stringify({ id: 42 }),
    });
  });

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

  // прив'язка до ОСНОВНОГО методу, не до випадкового OPTIONS
  const resPromise = page.waitForResponse(
    (r) => r.url().includes('/orders') && r.request().method() === 'POST',
  );
  await page.click('#place-order');
  const res = await resPromise;

  expect(res.status()).toBe(201);
});

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

• Мок мусить окремо відповісти на OPTIONS. Без гілки для preflight основний POST не полетить, і тест впаде з Response to preflight request doesn't pass — CORS-помилка, «якої не мало бути». Мокаючи крос-орідж-відповідь, завжди додавай Access-Control-Allow-*.
• waitForResponse прив'язуй до основного методу й URL. Один логічний запит = два мережеві записи (OPTIONS + POST). Якщо чекання зловить OPTIONS, тест плаватиме: інколи повертає preflight, інколи справжню відповідь.
• Access-Control-Allow-Origin треба і на preflight, і на основній відповіді. Пройшов OPTIONS, але на відповіді 201 заголовка немає → браузер не віддасть тіло скрипту, тест побачить CORS-помилку вже на другому кроці.
• Якщо запит іде з credentials: 'include' — Access-Control-Allow-Origin: * у моці не спрацює: для credentials треба конкретне походження плюс Access-Control-Allow-Credentials: true.

Кейс 3. APIRequestContext проходить, а браузер — ні: не той інструмент для CORS

«У Postman усе працює, значить бекенд правий» — хибна теза. Postman, curl та APIRequestContext у Playwright — це HTTP-клієнти, а не браузери: SOP вони не реалізують і CORS-заголовки просто ігнорують. Тому один і той самий сервер поводиться по-різному залежно від того, ким його б'єш.

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

// APIRequestContext — HTTP-клієнт, а не браузер: CORS йому байдуже
test('seeding через API проходить попри CORS', async ({ request }) => {
  const res = await request.post('https://api.example.com/orders', {
    headers: { origin: 'https://evil.example.com' }, // навіть чужий origin — 201
    data: { sku: 'A-1', qty: 2 },
  });
  expect(res.status()).toBe(201); // зелено, бо SOP тут не діє
});

// той самий бекенд у браузері блокується, якщо ACAO не дозволяє походження
test('браузерний CORS реально блокує читання відповіді', async ({ page }) => {
  await page.goto('https://app.example.com/checkout');
  const result = await page.evaluate(async () => {
    try {
      const r = await fetch('https://api.example.com/orders', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ sku: 'A-1', qty: 2 }),
      });
      return { ok: true, status: r.status };
    } catch (e) {
      return { ok: false, error: String(e) }; // TypeError: Failed to fetch
    }
  });
  expect(result.ok).toBe(false); // браузер не дав прочитати відповідь
});

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

• Зелений API-тест не доводить, що з CORS усе гаразд. request.post віддасть 201 навіть з Origin: https://evil.example.com, бо не перевіряє Access-Control-Allow-Origin. Щоб відтворити саме браузерну CORS-помилку, потрібен реальний браузерний контекст (E2E через page), а не API-клієнт.
• Заблокований CORS ≠ запит не дійшов. Для простого запиту сервер виконує його повністю — база оновлюється, лист іде — браузер лише не дає скрипту прочитати відповідь. Тому не покладайся на «браузер же заблокував» як на захист від зміни стану: прибирай дані явно між тестами.
• APIRequestContext — ідеальний для seeding в обхід CORS. Готуй стан через API незалежно від CORS-налаштувань стенду. Тільки не плутай це з перевіркою: такою перевіркою браузерний баг ти не спіймаєш.
• «Розлогінування» посеред E2E на різних портах часто виявляється недоналаштованим Access-Control-Allow-Credentials або Access-Control-Allow-Origin: * разом із credentials, а не багом застосунку. Фронт на localhost:3000 та API-мок на localhost:4000 — це вже два різні походження.

Origin і Same-Origin Policy

• Можу назвати, з чого складається походження (origin): схема + хост + порт; шлях, query і фрагмент не рахуються.
• Розумію, чому піддомен — це інший origin, а https://site.com і https://site.com:443 — той самий (порт за замовчуванням залежить від схеми: 443 для https, 80 для http).
• Знаю, що фронт на localhost:3000 і мок-API на localhost:4000 — це два різні походження (різні порти) з усіма крос-орідж-правилами.
• Можу пояснити, що робить Same-Origin Policy (SOP): забороняє скрипту читати дані з чужого походження, але не блокує саме звернення до ресурсу.
• Знаю, що SOP блокує читання відповіді fetch/XHR, DOM чужого <iframe>, cookie й localStorage іншого origin, але НЕ блокує <img>, <script> чи відправлення форми на чуже походження.
• Розумію окремий випадок Origin: null (напр. sandboxed <iframe> без allow-same-origin) і чому сервер має свідомо вирішувати, як з ним чинити.

Чому img/script не блокуються, JSONP і CSRF

• Можу пояснити, чому <img> і <script> історично не під SOP: вбудувати (embed) чуже можна, а прочитати вміст скриптом — ні (чуже зображення «забруднює» canvas і блокує getImageData/toDataURL).
• Знаю, що таке JSONP і чому це історичний обхід SOP до появи CORS (сервер повертав callback({...}) через <script>).
• Можу пояснити різницю CORS vs CSRF: CORS про читання відповіді, CSRF про небажану дію (браузер підставляє cookie в запит на чуже походження).

CORS: заголовки й механіка

• Розумію, що CORS дозволяє серверу явно дозволити чужим походженням читати свої відповіді через HTTP-заголовки.
• Можу пояснити роль Access-Control-Allow-Origin (ACAO) і три його стани: конкретне походження, *, або відсутній (доступ заблоковано).
• Знаю, навіщо при echo Origin за білим списком потрібен Vary: Origin — інакше кеш/CDN віддасть чужу закешовану відповідь і буде флакова CORS-помилка.
• Розумію, що скрипт за замовчуванням бачить лише 7 safelisted-заголовків відповіді, а решту (напр. X-Total-Count) треба перелічити у Access-Control-Expose-Headers.

Простий запит, preflight і credentials

• Можу назвати умови «простого» запиту (метод GET/HEAD/POST, safelist-заголовки, Content-Type з трьох дозволених) і чому майже будь-який реальний API-запит тягне preflight.
• Розумію, що preflight — це автоматичний OPTIONS із Access-Control-Request-Method/-Headers, який має пройти (2xx-статус) перед справжнім запитом; сам preflight іде без тіла й без credentials.
• Знаю роль Access-Control-Max-Age (кеш preflight) і що браузери ріжуть його згори (Chromium — 7200 с, Firefox — 86400 с).
• Розумію правила режиму credentials (credentials: 'include'): не можна * у ACAO, обовʼязково Access-Control-Allow-Credentials: true, * не діє як «усі» для Headers/Methods.

Браузер vs сервер, діагностика й автотести

• Можу пояснити, чому CORS «працює» в браузері, але не в curl/Postman/APIRequestContext: CORS перевіряє браузер, а не сервер; HTTP-клієнти ігнорують Access-Control-*.
• Розумію, чому «в Postman/curl 200» не доводить правоту бекенду в контексті браузера.
• Розумію, що для простого запиту сервер виконує його повністю (побічні ефекти стаються) — браузер лише не дає прочитати відповідь; для preflight основний запит може взагалі не полетіти.
• Знаю, що CORS майже завжди лагодить бекенд (заголовки віддає сервер), крім фронтових випадків: забутий credentials: 'include', зайвий заголовок → зайвий preflight, або обхід через dev-проксі.
• Розумію наслідки для автотестів: мокати OPTIONS разом із CORS-заголовками, чіпляти waitForResponse до основного методу (а не OPTIONS), сідати стан через API в обхід SOP і явно прибирати стан (заблокований CORS ≠ запит не дійшов).