CORS Проверка

Разбиране на CORS политиката и ролята на заглавките

Споделянето на ресурси с различен произход (CORS) е критичен механизъм за сигурност, вграден в уеб браузърите. Той определя дали клиентският код, изпълняван в браузъра, има разрешение да чете отговор, получен от друг произход (домейн, схема или порт), различен от този, от който е зареден самият уеб сайт. Когато се извършва заявка с различен произход, браузърът анализира специфични HTTP заглавки в отговора на сървъра, за да реши дали да предостави достъп до данните.

Инструментът CORS Проверка помага на разработчиците да симулират това поведение на браузъра. Чрез анализиране на предоставените HTTP заглавки на отговора и параметрите на планираната заявка, инструментът определя дали браузърът би разрешил или блокирал достъпа.

Разлики между действителен отговор и отговор преди полет (Preflight)

При CORS заявките съществуват два основни сценария, които браузърът обработва по различен начин:

1. Действителен отговор: Това е директният отговор от сървъра при прости заявки. Браузърът проверява заглавките на този отговор, за да реши дали клиентският код може да прочете съдържанието му.
2. Отговор преди полет: За по-сложни заявки (например такива, използващи методи като PUT или DELETE, или съдържащи потребителски заглавки) браузърът автоматично изпраща предварителна заявка с метода OPTIONS. Този предварителен тест проверява дали сървърът одобрява последващия метод и заявените имена на заглавки.

В CORS Проверка потребителят може да избере опцията за Отговор за проверка между Действителен отговор и Отговор преди полета. При проверка на предварителен отговор е необходимо да се постави и редът за състоянието (HTTP status line), тъй като успешният статус е задължителен за валидирането на предполета.

Изисквания към входните данни

За да извърши точен анализ, инструментът изисква следните входни параметри:

• Заглавки на HTTP отговор: Текстово поле с максимална дължина от 200 000 знака. При празно поле се извежда съобщението: „Поставете заглавки на HTTP отговор преди проверка.“. Ако лимитът бъде надвишен, се показва: „Този отговор е необичайно голям. Съхранявайте го под знаци ‹max›.“. Всеки ред трябва да бъде валиден HTTP хедър или ред на състоянието, в противен случай се показва грешка: „Редът ‹line› не е валиден HTTP хедър или ред на състоянието.“ или „Редът ‹line› съдържа невалидно име на HTTP заглавка.“.
• Заявка за произход: Схемата, хостът и незадължителният порт на произхода (например https://app.example.com). Въвеждането на път, заявка (query) или идентификационни данни води до грешката: „Въведете произход само със схема, хост и незадължителен порт, като https://app.example.com.“.
• Искан метод: HTTP методът на заявката. Невалидни токени предизвикват грешката: „Въведете валиден токен за HTTP метод.“. Ако се използва забранен метод, се показва: „Браузърите не позволяват метода ‹method› в заявките fetch.“.
• Заявени имена на заглавки: Имената на заглавките от Access-Control-Request-Headers, разделени със запетаи или нови редове. Невалидно име води до съобщението: „„‹header›“ не е валидно име на заглавка на HTTP заявка.“.
• Включете идентификационни данни: Превключвател, указващ дали заявката съдържа бисквитки или HTTP удостоверяване.

Правила за валидация и обработка на заглавките

Инструментът прилага стриктно правилата на CORS спецификацията:

Ролята на Access-Control-Allow-Origin

Тази заглавка указва кои домейни имат достъп до ресурса.

• Ако стойността съвпада точно с изпратения произход, се прилага правилото: „Access-Control-Allow-Origin съвпада точно с ‹origin›.“.
• Ако заглавката позволява всякакъв произход чрез заместващ знак, се извежда: „Access-Control-Allow-Origin позволява произволен произход за тази заявка.“.
• Липсата на заглавката води до блокиране: „Access-Control-Allow-Origin липсва.“.
• Ако стойността съдържа няколко произхода или е разделена със запетаи, тя се счита за невалидна: „Access-Control-Allow-Origin има невалидна стойност: ‹value›.“.

Влияние на идентификационните данни (Credentials)

Когато заявката включва идентификационни данни (бисквитки или HTTP удостоверяване), се задействат допълнителни ограничения:

• Заглавката Access-Control-Allow-Origin не може да използва заместващия знак *. При нарушение се показва: „Access-Control-Allow-Origin не може да бъде *, когато са включени идентификационни данни.“.
• Заглавката Access-Control-Allow-Credentials трябва да бъде точно true. Ако липсва или е различна, се показва: „Заявка с удостоверение изисква Access-Control-Allow-Credentials: вярно.“.
• Ако не са включени идентификационни данни, тази заглавка не влияе на решението: „Идентификационните данни не са включени, така че Access-Control-Allow-Credentials не влияе на това решение.“.
• При наличие на идентификационни данни, заместващите знаци (*) в Access-Control-Allow-Methods и Access-Control-Allow-Headers губят своето специално значение и се третират като обикновени низове.

Методи и заглавки при предварителна проверка (Preflight)

• Методи: Ако методът е CORS-безопасен (например GET, POST или HEAD), той не се нуждае от изрично одобрение: „‹method› е CORS-безопасен метод и не е необходимо да се появява в Access-Control-Allow-Methods.“. В противен случай се проверява дали е разрешен: „Предварителният полет позволява ‹method›.“ или „Access-Control-Allow-Methods не разрешава ‹method›.“.
• Заглавки: Ако няма заявени заглавки, се извежда: „Няма поискани имена на заглавки, които не се нуждаят от предварително одобрение.“. Заявка без идентификационни данни може да използва заместващ знак: „Access-Control-Allow-Headers: * покрива тези имена за заявка без идентификационни данни: ‹headers›.“.
• Специалното правило за Authorization: Заглавката Authorization трябва винаги да бъде изрично изброена в Access-Control-Allow-Headers. Заместващият знак * не я покрива, дори при заявки без идентификационни данни. При нарушение се показва: „Authorization трябва да бъде посочен изрично; Access-Control-Allow-Headers: * не го покрива.“.

HTTP статус на предварителната проверка

За успешна предварителна проверка сървърът трябва да върне статус от групата 2xx.

• При успешен статус се извежда: „Състоянието преди полет ‹status› е успешно.“.
• При неуспешен статус: „Статусът преди полет ‹status› не е успешен статус 2xx.“.
• Ако липсва ред за състоянието в поставения отговор, проверката е неопределена: „Не е поставен HTTP ред за състояние, така че изискваният 2xx статус за предполет не може да бъде проверен.“.

Поверителност и обработка на данните

Всички изчисления и анализи се извършват изцяло локално. Вашите заглавки и подробности за заявката остават във вашия браузър. Нищо не се качва или запазва от BroBroGo.

Инструментът работи изключително върху предоставените текстови данни. Той не се свързва с външни сървъри, не чете URL адреси, не задава бисквитки, не проверява DNS или TLS настройки и не променя конфигурации на сървъра. Преминаването на проверката в инструмента гарантира единствено съвместимост на анализираните заглавки, но не изключва блокиране на реалната заявка поради мрежови пренасочвания, кеширане, промени в правилата на сървъра или намеса от браузърни разширения.

Често задавани въпроси (FAQ)

Трябва ли да поставя действителния отговор или отговора преди полета?

Използвайте Действителен отговор, за да проверите дали кодът на браузъра може да прочете един отговор. Използвайте отговора Preflight за отговора OPTIONS, който одобрява по-късен метод и неговите заявени имена на заглавки.

Защо заместващият знак може да се провали с идентификационни данни?

Когато са включени бисквитки или HTTP удостоверяване, разрешеният произход трябва да съвпада точно с искащия произход. Заместващите символи за разрешени методи и заглавки също губят своето значение за заместващи знаци.

Успешният резултат доказва ли, че заявката на живо ще работи?

Не. Този резултат обхваща само поставения отговор и данните за заявката, въведени тук. Пренасочванията, кешираните отговори, промяната на правилата на сървъра, разширенията на браузъра и действителният отговор след предварителна проверка все още могат да променят резултата.

Как се обработва заглавката Authorization при използване на заместващ знак?

Заглавката Authorization е изключение от общото правило за заместващия знак. Тя трябва да бъде изрично посочена в Access-Control-Allow-Headers, тъй като стойността * не я покрива, независимо дали заявката включва идентификационни данни или не.