CORS-kontroll

Förståelse av CORS-policyn och webbläsarens beslut

Cross-Origin Resource Sharing (CORS) är en säkerhetsmekanism som webbläsare använder för att begränsa hur resurser på en webbsida kan begäras från ett annat ursprung än det som sidan själv lästes in från. När en webbapplikation försöker läsa ett svar från en annan server, utvärderar webbläsaren de HTTP-svarshuvuden som servern skickar tillbaka. Om serverns CORS-policy inte uttryckligen tillåter begäran, blockerar webbläsaren åtkomsten till svaret.

Detta verktyg, CORS-kontroll, hjälper dig att analysera om en webbläsare skulle tillåta en specifik cross-origin-begäran baserat på de HTTP-svarshuvuden du tillhandahåller och detaljerna för din begäran. Genom att klistra in svarshuvudena och ange parametrar som ursprung, metod, begärda huvudnamn samt om autentiseringsuppgifter ingår, kan du omedelbart se webbläsarens beslut.

Verktyget utför analysen lokalt. Dina huvuden och begäransuppgifter stannar i webbläsaren. Inget laddas upp till eller sparas av BroBroGo.

Indata och valideringsregler

För att utföra en kontroll krävs att du anger detaljerade uppgifter om både svaret och den tänkta begäran. Verktyget validerar indata noggrant och visar specifika felmeddelanden om något inte stämmer:

• Svar att kontrollera: Du väljer mellan "Faktiskt svar" och "Preflight-svar".
• HTTP-svarshuvuden: Textfältet tar emot dina HTTP-svarshuvuden, inklusive statusraden för preflight-svar, upp till maximalt 200 000 tecken.
  • Om fältet lämnas tomt visas felmeddelandet: "Klistra in HTTP-svarshuvuden innan du kontrollerar.".
  • Om texten överskrider gränsen visas: "Svaret är ovanligt stort. Håll det under ‹max› tecken.".
  • Om en rad inte kan tolkas visas: "Rad ‹line› är inte ett giltigt HTTP-huvud eller en giltig statusrad.".
  • Om ett huvudnamn är felaktigt visas: "Rad ‹line› innehåller ett ogiltigt HTTP-huvudnamn.".
• Begärans ursprung: Här anger du schema, värd och valfri port för det ursprung som gör begäran, till exempel https://app.example.com. Det måste vara ett rent ursprung eller null. Sökvägar, frågesträngar eller inloggningsuppgifter är inte tillåtna. Vid fel visas: "Ange ett ursprung med endast schema, värd och valfri port, till exempel https://app.example.com.".
• Begärd metod: HTTP-metoden som ska användas. Om token är ogiltig visas: "Ange en giltig HTTP-metodtoken.". Om du anger en metod som webbläsare blockerar i fetch-anrop visas: "Webbläsare tillåter inte metoden ‹method› i fetch-begäranden.".
• Begärda huvudnamn: De huvuden som skickas i Access-Control-Request-Headers, avgränsade med kommatecken eller radbrytningar (till exempel Content-Type, Authorization). Om ett ogiltigt namn anges visas: ”‹header›” är inte ett giltigt namn på ett HTTP-begäranshuvud.".
• Inkludera autentiseringsuppgifter: En inställning för om begäran inkluderar cookies eller HTTP-autentisering.

Om det finns generella problem med dina angivna värden visas felmeddelandet: "Rätta den markerade inmatningen och försök igen.".

Tolkning av webbläsarens beslut

När du har fyllt i uppgifterna och klickat på "Kontrollera CORS" visar verktyget ett av följande resultat under rubriken för webbläsarens beslut:

• Klistra in ett svar för att kontrollera dess CORS-policy. (Detta är det initiala tillståndet innan någon kontroll har gjorts).
• Ange ett svar och begäransuppgifter och kontrollera sedan CORS-policyn. (Visas om nödvändiga indata saknas).
• Tillåts av det inklistrade CORS-svaret..
• Blockeras av det inklistrade CORS-svaret..
• Huvudena godkänns, men preflight-statusen är okänd..

Verktyget presenterar även de tolkade Access-Control-*-fälten samt de specifika orsakerna till beslutet. Om ett fält saknas helt i svaret markeras det som "Saknas".

CORS-regler och hantering av autentiseringsuppgifter

När en begäran inkluderar autentiseringsuppgifter (såsom cookies eller HTTP-autentisering) skärper webbläsaren CORS-reglerna avsevärt:

• Inga jokertecken för ursprung: Huvudet Access-Control-Allow-Origin får inte vara ett jokertecken (*). Om det är det, blockeras begäran med motiveringen: "Access-Control-Allow-Origin kan inte vara * när autentiseringsuppgifter ingår.". Ursprunget måste matcha exakt, vilket bekräftas med: "Access-Control-Allow-Origin matchar exakt ‹origin›.".
• Krav på explicit tillåtelse: Huvudet Access-Control-Allow-Credentials måste vara exakt true. Om det saknas eller har ett annat värde visas: "En begäran med autentiseringsuppgifter kräver Access-Control-Allow-Credentials: true.". Om det är korrekt visas: "Access-Control-Allow-Credentials är exakt true.".
• Förlust av jokerteckenbetydelse: När autentiseringsuppgifter ingår förlorar jokertecken (*) i Access-Control-Allow-Methods och Access-Control-Allow-Headers sin speciella betydelse och tolkas istället bokstavligt, vilket oftast leder till att begäran blockeras.

Om autentiseringsuppgifter inte är inkluderade är reglerna mer tillåtande. Då påverkar inte Access-Control-Allow-Credentials beslutet, och jokertecken kan användas för att tillåta metoder och huvuden.

Preflight-begäranden och statuskoder

För vissa typer av cross-origin-begäranden skickar webbläsaren först en så kallad preflight-begäran med HTTP-metoden OPTIONS. Detta görs för att kontrollera om servern godkänner den faktiska metoden och de begärda huvudena innan den riktiga begäran skickas.

Vid kontroll av ett preflight-svar utvärderas följande regler:

• HTTP-statuskod: Preflight-svaret måste returnera en lyckad statuskod i 2xx-intervallet. Om statusraden saknas i det inklistrade svaret blir resultatet obestämt med motiveringen: "Ingen HTTP-statusrad klistrades in, så den obligatoriska 2xx-statusen för preflight kan inte kontrolleras.". Om statusen är felaktig visas: "preflight-statusen ‹status› är inte en lyckad 2xx-status.".
• Tillåtna metoder: Metoden måste antingen vara en CORS-säker metod (som inte kräver preflight-godkännande) eller uttryckligen tillåtas av Access-Control-Allow-Methods.
• Särskild hantering av Authorization: Huvudet Authorization har en särställning i CORS-specifikationen. Även om servern svarar med Access-Control-Allow-Headers: * för en begäran utan autentiseringsuppgifter, omfattar detta jokertecken inte Authorization. Detta huvud måste alltid listas uttryckligen i Access-Control-Allow-Headers. Om det saknas visas: "Authorization måste anges uttryckligen; Access-Control-Allow-Headers: * omfattar det inte.".

Verktygets omfattning och begränsningar

Detta verktyg är utformat för att analysera statiska svarshuvuden mot webbläsarens CORS-regler. Det är viktigt att förstå vad verktyget gör och inte gör:

• Det kontaktar inte någon server, läser inte externa URL:er, sätter inga cookies och kontrollerar inte DNS eller TLS.
• Det modifierar inte serverkonfigurationer.
• Ett godkänt resultat garanterar inte att en verklig begäran kommer att lyckas i en skarp miljö. Analysen kan inte ta hänsyn till efterföljande omdirigeringar, cachelagrade svar i webbläsaren, ändrade serverregler, installerade webbläsartillägg eller det faktiska svaret som returneras efter att en preflight har godkänts.

Vanliga frågor

Ska jag klistra in det faktiska svaret eller preflight-svaret?

Använd Faktiskt svar för att kontrollera om webbläsarkod kan läsa ett svar. Använd Preflight-svar för OPTIONS-svaret som godkänner en senare metod och de begärda huvudnamnen.

Varför kan ett jokertecken misslyckas med autentiseringsuppgifter?

När cookies eller HTTP-autentisering ingår måste det tillåtna ursprunget exakt matcha ursprunget som gör begäran. Jokertecken för tillåtna metoder och huvuden förlorar också sin jokerteckenbetydelse.

Bevisar ett godkänt resultat att den riktiga begäran fungerar?

Nej. Resultatet omfattar bara det inklistrade svaret och begäransuppgifterna som anges här. Omdirigeringar, cachelagrade svar, ändrade serverregler, webbläsartillägg och det faktiska svaret efter en preflight kan fortfarande ändra resultatet.

Hur hanteras mina data som jag klistrar in i verktyget?

Dina huvuden och begäransuppgifter stannar i webbläsaren. Inget laddas upp till eller sparas av BroBroGo.