CORS-tjek

Forståelse af CORS-politikken i webbrowsere

Cross-Origin Resource Sharing (CORS) er en sikkerhedsmekanisme, som browsere håndhæver for at kontrollere, om et script på et websted må læse ressourcer fra en anden oprindelse. En oprindelse defineres ud fra skema, vært og port. Når en webapplikation forsøger at foretage en cross-origin-anmodning, analyserer browseren de HTTP-svarheadere, som serveren returnerer, for at afgøre, om anmodningen skal tillades eller blokeres.

Dette CORS-tjek værktøj simulerer denne browseradfærd. Ved at analysere de rå HTTP-svarheadere og sammenholde dem med parametrene for din planlagte anmodning, kan du identificere, hvorfor en browser tillader eller blokerer en bestemt handling. Værktøjet udfører udelukkende denne analyse lokalt. Dine overskrifter og anmodningsdetaljer bliver i din browser, og intet er uploadet til eller gemt af BroBroGo. Værktøjet kontakter ikke eksterne servere, læser ikke URL'er, sætter ikke cookies, kontrollerer ikke DNS/TLS og ændrer ikke serverkonfigurationer.

Inputparametre og valideringsregler

For at udføre en nøjagtig evaluering kræver værktøjet specifikke oplysninger om både svaret og den planlagte anmodning:

• Svar på kontrol: Du skal vælge mellem "Faktisk svar" eller "Preflight-svar".
• HTTP-svar-headere: Indtast de rå HTTP-svarheadere, som serveren returnerer. Tekstfeltet accepterer maksimalt 200.000 tegn. Hvis feltet efterlades tomt, vises fejlen "Indsæt HTTP-svarheaders før kontrol.". Hvis inputtet overskrider grænsen, vises "Denne respons er usædvanlig stor. Opbevar det under ‹max›-tegn.". Hver linje skal være en gyldig HTTP-header eller statuslinje, ellers udløses "Linje ‹line› er ikke en gyldig HTTP-header eller statuslinje." eller "Linje ‹line› indeholder et ugyldigt HTTP-headernavn.".
• Anmod om oprindelse: Angiv den oprindelse, hvorfra anmodningen afsendes. Dette skal være en ren oprindelse (f.eks. https://app.example.com) eller null. URL-stier, forespørgselsparametre (queries) eller legitimationsoplysninger er ikke tilladt. Ugyldige formater udløser fejlen "Indtast en oprindelse med kun et skema, vært og valgfri port, såsom https://app.example.com.".
• Ønsket metode: Den HTTP-metode (f.eks. GET, POST, OPTIONS), som anmodningen bruger. Hvis formatet er forkert, vises "Indtast et gyldigt HTTP-metodetoken.". Hvis metoden er blokeret af browseren generelt, vises "Browsere tillader ikke ‹method›-metoden i fetch-anmodninger.".
• Anmodede headernavne: De headere, som anmodningen vil inkludere, svarende til værdierne i Access-Control-Request-Headers. Disse adskilles af kommaer eller linjeskift. En ugyldig header udløser fejlen "‹header›" er ikke et gyldigt HTTP-anmodningshovednavn.".
• Inkluder legitimationsoplysninger: En omskifter, der angiver, om anmodningen inkluderer cookies eller HTTP-godkendelse.

Hvis der er generelle problemer med de indtastede data, vil værktøjet vise meddelelsen "Ret det fremhævede input, og prøv igen.".

Evaluering af faktiske svar versus preflight-svar

CORS skelner skarpt mellem det faktiske svar og et preflight-svar. Et faktisk svar evalueres, når browseren skal afgøre, om koden på websiden må læse de returnerede data. Et preflight-svar er resultatet af en OPTIONS-anmodning, som browseren sender i forvejen for at undersøge, om serveren tillader den reelle metode og de anmodede headere.

Hvis du vælger "Preflight-svar", skal du inkludere HTTP-statuslinjen i dine indsatte svarheadere. Hvis statuslinjen mangler, vil resultatet for preflight-kontrollen være ubestemt, og værktøjet rapporterer "Ingen HTTP-statuslinje blev indsat, så den påkrævede 2xx preflight-status kan ikke kontrolleres.". En succesfuld preflight kræver en statuskode i 2xx-området. Hvis statuskoden ikke er succesfuld, rapporteres "Preflight-statussen ‹status› er ikke en vellykket 2xx-status.".

Håndtering af legitimationsoplysninger og jokertegn

Når en anmodning inkluderer legitimationsoplysninger (cookies eller HTTP-godkendelse), gælder der strenge regler for CORS-headere:

1. Oprindelse: Headeren Access-Control-Allow-Origin må ikke indeholde jokertegnet *. Hvis der bruges et jokertegn sammen med legitimationsoplysninger, vil anmodningen blive blokeret med begrundelsen "Access-Control-Allow-Origin kan ikke være *, når legitimationsoplysninger er inkluderet.". Oprindelsen skal i stedet matches nøjagtigt.
2. Metoder og headere: Jokertegn i Access-Control-Allow-Methods og Access-Control-Allow-Headers mister deres betydning som universelle tilladelser, når der anmodes med legitimationsoplysninger.
3. Eksplicit godkendelse: Headeren Access-Control-Allow-Credentials skal være sat til nøjagtigt true. Hvis denne mangler eller er sat til andet, blokeres anmodningen med begrundelsen "En legitimationsanmodning kræver Access-Control-Allow-Credentials: sand.".

Hvis anmodningen derimod ikke inkluderer legitimationsoplysninger, kan jokertegnet * anvendes bredt til at tillade metoder og headere. Der er dog en vigtig undtagelse: Headeren Authorization skal altid være eksplicit angivet i Access-Control-Allow-Headers. Selvom Access-Control-Allow-Headers: * er til stede, dækker det ikke over Authorization-headeren, og værktøjet vil rapportere "Authorization skal angives eksplicit; Access-Control-Allow-Headers: * dækker det ikke.".

Fortolkning af browserens beslutning

Når du har indtastet dine data og klikket på "Tjek CORS", vil værktøjet vise en af følgende primære statusser under "Browser beslutning":

• Tilladt af det indsatte CORS-svar.
• Blokeret af det indsatte CORS-svar.
• Overskrifter passerer, men preflight-status er ukendt.

Værktøjet viser også de analyserede felter under "Parsed Access-Control felter". Hvis en header mangler i svaret, markeres den som "Ikke til stede".

Det er vigtigt at bemærke, at et grønt eller bestået resultat i dette værktøj udelukkende baserer sig på de statiske data, du har indtastet. Evalueringen tager ikke højde for efterfølgende omdirigeringer (redirects), cachelagrede svar i browseren, dynamiske ændringer i serverens regler, aktive browserudvidelser eller det faktiske svar, der modtages efter en godkendt preflight-anmodning.

Ofte stillede spørgsmål (FAQ)

Skal jeg indsætte det faktiske svar eller preflight-svaret?
Brug Faktisk svar til at kontrollere, om browserkoden kan læse ét svar. Brug Preflight-svar til OPTIONS-svaret, der godkender en senere metode og dens anmodede headernavne.

Hvorfor kan et jokertegn mislykkes med legitimationsoplysninger?
Når cookies eller HTTP-godkendelse er inkluderet, skal den tilladte oprindelse matche den anmodende oprindelse nøjagtigt. Jokertegn for tilladte metoder og overskrifter mister også deres jokertegnsbetydning.

Beviser et bestået resultat, at live-anmodningen vil fungere?
Nej. Dette resultat dækker kun det indsatte svar og de anmodningsdetaljer, der indtastes her. Omdirigeringer, cachelagrede svar, ændring af serverregler, browserudvidelser og det faktiske svar efter en preflight kan stadig ændre resultatet.

Hvorfor fejler min Authorization-header, selvom jeg bruger et jokertegn?
Selvom Access-Control-Allow-Headers: * er angivet, dækker dette jokertegn ikke over Authorization-headeren. Denne specifikke header skal altid være eksplicit nævnt i serverens Access-Control-Allow-Headers-felt for at blive godkendt af browseren.