Verificator CORS

Înțelegerea politicii Cross-Origin Resource Sharing (CORS)

Mecanismul Cross-Origin Resource Sharing (CORS) este o măsură de securitate implementată de browserele web pentru a restricționa modul în care resursele de pe un domeniu pot fi solicitate de scripturi care rulează pe o altă origine. O origine este definită prin combinația unică de schemă (protocol), gazdă (host) și port. Atunci când o aplicație web încearcă să efectueze o cerere HTTP cross-origin, browserul evaluează regulile CORS pe baza antetelor trimise de server pentru a decide dacă permite sau blochează accesul la răspuns.

Acest instrument analizează antetele de răspuns HTTP furnizate și detaliile cererii pentru a determina dacă un browser ar permite accesul la date. Evaluarea se bazează strict pe regulile standard de securitate ale browserelor, oferind o analiză clară a modului în care sunt interpretate antetele de control al accesului.

Rolul antetului Access-Control-Allow-Origin

Antetul Access-Control-Allow-Origin este cel mai important element al unei politici CORS. Acesta indică browserului ce origini au permisiunea de a citi datele din răspuns.

Atunci când se evaluează acest antet, pot apărea mai multe scenarii de validare:

• Potrivire exactă: Valoarea antetului corespunde exact cu originea solicitantă. În acest caz, instrumentul afișează mesajul: „Access-Control-Allow-Origin se potrivește exact cu ‹origin›.”.
• Wildcard: Valoarea este setată ca *, permițând accesul general. Mesajul asociat este: „Access-Control-Allow-Origin permite orice origine pentru această cerere.”.
• Lipsa antetului: Dacă serverul nu trimite acest antet, browserul blochează automat cererea. Mesajul generat este: „Access-Control-Allow-Origin lipsește.”.
• Nepotrivire: Când valoarea returnată nu coincide cu originea cererii, se afișează: „Access-Control-Allow-Origin este ‹actual›, nu ‹expected›.”.
• Valoare invalidă: Dacă antetul conține mai multe valori sau este separat prin virgulă, acesta este considerat neconform. Mesajul de eroare este: „Access-Control-Allow-Origin are o valoare invalidă: ‹value›.”.

Funcționarea cererilor de tip Preflight

Pentru anumite cereri cross-origin (cum ar fi cele care folosesc alte metode decât GET, HEAD sau POST, sau cele care trimit antete personalizate), browserul trimite automat o cerere preliminară de tip OPTIONS. Aceasta este cunoscută sub numele de cerere preflight. Scopul ei este de a verifica dacă serverul aprobă metoda și antetele pe care aplicația dorește să le trimită în cererea reală.

În cadrul acestei verificări, antetele Access-Control-Allow-Methods și Access-Control-Allow-Headers joacă un rol critic:

• Metode permise: Dacă metoda solicitată este aprobată, se confirmă prin: „Preflight permite ‹method›.”. Dacă metoda este una standard, scutită de preflight, se afișează: „‹method› este o metodă CORS-listată în siguranță și nu trebuie să apară în Access-Control-Allow-Methods.”. În caz contrar, se aplică regula: „Access-Control-Allow-Methods nu permite ‹method›.”.
• Antete permise: Când antetele solicitate sunt aprobate de server, se afișează: „Preflight-ul permite denumirile de antet solicitate: ‹headers›.”. Dacă nu sunt solicitate antete speciale, se aplică regula: „Niciun nume de antet cerut nu necesită aprobare preflight.”. Dacă serverul respinge antetele, mesajul este: „Access-Control-Allow-Headers nu permite: ‹headers›.”.

Impactul acreditărilor asupra politicii CORS

Atunci când o cerere cross-origin este configurată să includă acreditări (cum ar fi cookie-uri sau antete de autentificare HTTP), regulile CORS devin mult mai stricte pentru a preveni scurgerile de date sensibile.

Dacă acreditările sunt incluse, dar antetul Access-Control-Allow-Origin este setat ca *, browserul va bloca cererea, generând eroarea: „Access-Control-Allow-Origin nu poate fi * când sunt incluse acreditările.”. De asemenea, dacă antetul de aprobare a acreditărilor lipsește sau nu este configurat corect, se aplică regula: „O cerere acreditată trebuie Access-Control-Allow-Credentials: adevărată.”. Dacă cererea nu include acreditări, starea acestui antet nu influențează decizia: „Acreditările nu sunt incluse, deci Access-Control-Allow-Credentials nu influențează această decizie.”.

Comportamentul wildcard-urilor și gestionarea antetului Authorization

Deși utilizarea caracterului wildcard (*) simplifică configurarea CORS pentru resursele publice, acesta are limitări stricte în prezența acreditărilor și în cazul anumitor antete sensibile.

O excepție majoră de la utilizarea wildcard-ului în antetul Access-Control-Allow-Headers este antetul Authorization. Chiar dacă serverul returnează Access-Control-Allow-Headers: *, acest wildcard nu acoperă antetul de autorizare. Acesta trebuie să fie listat în mod explicit în lista de antete permise de pe server. În caz contrar, decizia va fi blocată cu explicația: „Authorization trebuie enumerate explicit; Access-Control-Allow-Headers: * nu acoperă.”. Pentru alte antete standard, în absența acreditărilor, wildcard-ul funcționează normal: „Access-Control-Allow-Headers: * acoperă aceste nume pentru o cerere fără acreditări: ‹headers›.”.

Importanța codurilor de stare HTTP în răspunsurile Preflight

Pentru ca o verificare preflight să fie considerată validă de către browser, răspunsul la cererea OPTIONS trebuie să returneze un cod de stare HTTP de succes din gama 2xx (de obicei 200 sau 204).

Dacă analizați un răspuns preflight, prezența liniei de stare HTTP este obligatorie pentru o evaluare completă. Dacă linia de stare indică succes, se aplică regula: „Starea de prezbor ‹status› este reușită.”. Dacă serverul returnează un cod de eroare (cum ar fi 400 sau 500), verificarea eșuează: „Statutul preflight ‹status› nu este un status 2xx de succes.”. În cazul în care lipiți doar antetele fără linia de stare HTTP, instrumentul nu poate confirma validitatea codului, rezultând o stare nedeterminată: „Nu a fost lipită nicio linie de HTTP status, astfel încât starea necesară 2xx preflight nu poate fi verificată.”.

Modul de procesare și limitele de verificare

Acest instrument rulează în întregime la nivel local. Toate antetele introduse și detaliile cererilor sunt procesate direct în browserul dumneavoastră. Datele nu sunt încărcate pe servere externe și nu sunt salvate de BroBroGo.

Trebuie avut în vedere că instrumentul analizează exclusiv textul antetelor introduse și parametrii selectați. Acesta nu efectuează conexiuni de rețea, nu apelează URL-uri live, nu citește și nu setează cookie-uri, nu verifică înregistrările DNS sau certificatele TLS și nu poate modifica configurația serverelor dumneavoastră. Un rezultat pozitiv indică doar faptul că datele introduse sunt conforme cu regulile CORS, dar nu garantează funcționarea unei cereri live în prezența unor factori externi precum redirecționările, politicile de cache ale browserului, extensiile active sau modificările dinamice ale regulilor de pe server.

Întrebări frecvente (FAQ)

Ar trebui să lipesc răspunsul propriu-zis sau răspunsul pre-flight?
Folosește Răspuns real pentru a verifica dacă codul browserului poate citi un răspuns. Folosește răspunsul Preflight pentru răspunsul OPTIONS care aprobă o metodă ulterioară și numele anteturilor solicitate.

De ce poate un wildcard să eșueze cu acreditările?
Când sunt incluse cookie-uri sau autentificare HTTP, originea permisă trebuie să corespundă exact cu originea solicitantă. Wildcard-urile pentru metodele permise și head-urile își pierd, de asemenea, sensul de wildcard.

Un rezultat de trecere dovedește că cererea live va funcționa?
Nu. Acest rezultat acoperă doar răspunsul lipit și detaliile cererii introduse aici. Redirecționările, răspunsurile stocate în cache, schimbarea regulilor serverului, extensiile browserului și răspunsul propriu-zis după un preflight pot totuși schimba rezultatul.