Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
По одному джерелу в рядку, до десяти. Корисно, щоб переконатися, що локальне, тестове та робоче середовища є у списку дозволених. Результати з'являються таблицею на вкладці Заголовки.
Ці запити надсилаються з серверів POLPROG до вказаної вами кінцевої точки, бо браузер не може виконати таку діагностику сам щодо себе: саме CORS йому б це заблокував. Жоден ваш файл cookie не пересилається, тіло запиту не надсилається ніколи, тіла відповідей відкидаються, і після того, як звіт дійде до вас, нічого не зберігається.
Це правило браузера, а не сервера. Коли JavaScript на одному джерелі просить ресурс на іншому, браузер надсилає запит, але відмовляється передати відповідь вашому коду, доки сервер у заголовках відповіді не скаже, що джерело, яке запитує, може її прочитати. Cross-Origin Resource Sharing це набір заголовків, якими це кажуть.
Якщо запит працює в curl, Postman, Insomnia чи з вашого власного бекенду, це нічого не каже про те, чи зможе його прочитати JavaScript у браузері. Ці клієнти не застосовують жодних правил CORS. Сервер зазвичай поводиться однаково в обох випадках; різниця цілком у тому, що робить з відповіддю той, хто викликає.
Для всього, окрім найпростіших запитів, браузер спершу надсилає запит OPTIONS, щоб спитати, чи дозволено справжній. Він несе Origin, Access-Control-Request-Method і, за потреби, Access-Control-Request-Headers. Якщо відповідь не дозволяє запит, справжній не надсилається взагалі, тож кінцева точка його ніколи не бачить, а в журналах вашого сервера нічого немає.
Запит простий лише тоді, коли його метод це GET, HEAD або POST і кожен заголовок, який він задає, є в безпечному списку CORS: Accept, Accept-Language, Content-Language, Content-Type і Range. Значення теж важить. Content-Type залишається в безпечному списку лише для application/x-www-form-urlencoded, multipart/form-data і text/plain.
Його немає у списку з трьох безпечних типів вмісту. Причина саме в цьому. POST із тілом JSON це запит із preflight, і саме тому додавання API JSON до наявної сторінки раптом породжує запит OPTIONS, якого ніхто не писав, і помилки з маршруту, що обробляє лише POST.
Або одне джерело, або *. Ніколи не список, ніколи не значення зі шляхом, ніколи не зірочка всередині імені хоста. Порівняння з джерелом, яке робить запит, точне, тож коса риска в кінці, явно виписаний стандартний порт або http там, де запит використав https, спричинять збій, хоча людині все це виглядає однаково.
Потрібен, коли запит надсилає файли cookie або автентифікацію HTTP. Єдине прийнятне значення це точний рядок true у нижньому регістрі. Запит з обліковими даними також не можна задовольнити через Access-Control-Allow-Origin: *, а для того самого запиту зірочка в Allow-Methods, Allow-Headers чи Expose-Headers перестає бути символом підстановки і стає буквальною назвою.
Якщо сервер бере значення Allow-Origin із вхідного запиту, відповідь залежить від заголовка Origin, і будь-який спільний кеш треба про це попередити. Без Vary: Origin CDN або зворотний проксі може зберегти відповідь, що називає одне джерело, і віддати її іншому, тож запити ламаються з причин, яких у застосунку взагалі не видно.
Відповідь з іншого джерела відкриває скриптові лише сім заголовків: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified і Pragma. Усе інше, включно з вашими власними заголовками X- та Location, читається як null, доки його не названо в Access-Control-Expose-Headers. Той заголовок стосується відповіді і не пов'язаний з Allow-Headers, який стосується запиту.
Він вирішує, які джерела можуть прочитати відповідь у браузері. Він не вирішує, хто може викликати кінцеву точку, не надає жодних дозволів і не спиняє міжсайтову підробку запитів: атаці CSRF не потрібно читати відповідь, тож сувора політика CORS її не зачіпає. Залиште автентифікацію, авторизацію і токени CSRF рівно такими, якими вони були.
Кожен висновок тут походить із реального обміну з указаною вами кінцевою точкою, оціненого за правилами Fetch standard, які застосовує браузер. Він описує кінцеву точку такою, якою вона відповіла інфраструктурі POLPROG у той момент: сервер, що змінює відповідь залежно від мережі, регіону чи автентифікації, може відповісти вашому браузеру інакше. Час виміряно з нашої інфраструктури, і це не вимірювання браузера. Перевірку справжнього запиту типово вимкнено для методів, які можуть змінювати дані, а тіло запиту не надсилається ніколи.
Бо CORS застосовують браузери і більше ніхто. Postman, curl, Insomnia і ваш власний бекенд не застосовують жодних правил CORS, тож отримують відповідь із будь-якими заголовками. Сервер зазвичай поводиться однаково в обох випадках. Різниця цілком у тому, що робить з відповіддю той, хто викликає, а браузер відмовляється передати її вашому JavaScript, доки відповідь не скаже, що це джерело може її прочитати.
Це запит OPTIONS, який браузер надсилає перед справжнім, щоб спитати, чи дозволено справжній. Він несе Origin, Access-Control-Request-Method і, за потреби, Access-Control-Request-Headers. Якщо відповідь не дозволяє запит, справжній не надсилається взагалі, тож ваша кінцева точка його ніколи не бачить, а в журналах сервера нічого немає. Preflight роблять лише для запитів, які не є простими.
Content-Type є в безпечному списку CORS лише для application/x-www-form-urlencoded, multipart/form-data і text/plain. Саме ці три і жодного більше. Тіло JSON виводить запит за межі безпечного списку, тож браузер оголошує його наперед. Саме тому додавання API JSON до наявної сторінки раптом породжує запит OPTIONS, якого ніхто не писав.
Бо відповідь, прив'язана до користувача, який увійшов у систему, не повинна бути доступною для читання кожному сайту, який цей користувач відвідує. Коли запит надсилає файли cookie або автентифікацію HTTP, сервер має назвати джерело, якому він довіряє, а браузер відхиляє зірочку одразу, навіть поруч із Access-Control-Allow-Credentials: true. Те саме стосується зірочки в Allow-Methods, Allow-Headers і Expose-Headers: для запиту з обліковими даними кожну з них читають як буквальну назву заголовка, а не як символ підстановки.
Ні. CORS вирішує, які джерела можуть прочитати відповідь усередині браузера. Це не автентифікація, він не надає жодних дозволів і не спиняє міжсайтову підробку запитів, бо атаці CSRF не потрібно читати відповідь. Будь-який клієнт, що не є браузером, повністю його ігнорує. Залиште автентифікацію, перевірки авторизації і токени CSRF рівно такими, якими вони є.
З серверів POLPROG до вказаної вами кінцевої точки, бо браузер не може виконати таку діагностику сам щодо себе: саме CORS йому б це заблокував. Надсилаються лише заголовки, потрібні для аналізу, жоден ваш файл cookie не пересилається, тіло запиту не надсилається ніколи, а тіла відповідей відкидаються. Після того, як звіт дійде до вас, нічого не зберігається, а значення чутливих заголовків, як-от Authorization, ніколи не показуються і не експортуються.
Організація часто шукає «один security scanner», але реальна задача має кілька шарів:
Заголовки безпеки HTTP дозволяють серверу передати браузеру правила завантаження скриптів, використання frame, функцій пристрою, referrer-інформації, MIME-типів і HTTPS. Правильно підібрана конфігурація обмежує наслідки XSS, clickjacking, MIME confusion, XS-Leaks і небажаного cross-origin вбудовування.
Якісний аудит сайту - це не одна оцінка Lighthouse і не список із десятків автоматичних попереджень. Він має відповісти на чотири запитання: чи може пошукова система правильно знайти й зрозуміти сайт, чи може користувач без перешкод виконати своє завдання, чи достатньо швидко працює сайт і чи не створює він зайвих ризиків для власника або відвідувачів?
Ми створюємо індивідуальне програмне забезпечення та рішення, адаптовані до ваших потреб.