CORS-sjekk

Forståelse av Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) er en sikkerhetsmekanisme som kjører i nettleseren for å kontrollere om skript som kjører på et nettsted, kan lese ressurser fra en annen opprinnelse. En opprinnelse defineres av skjema (protokoll), vert og eventuell port. Når en nettleser sender en forespørsel på tvers av opprinnelser, bruker den HTTP-svarhoder fra serveren til å avgjøre om dataene kan gjøres tilgjengelige for kildekoden.

CORS-sjekk er et verktøy som analyserer disse mekanismene lokalt. Verktøyet hjelper front-end-utviklere, back-end-utviklere, API-plattformutviklere og operasjonsutviklere med å forstå om nettleserkoden vil tillate eller blokkere en spesifikk forespørsel. Ved å analysere HTTP-svarhoder og forespørselsdetaljer, evaluerer verktøyet CORS-reglene uten å kontakte en ekstern server, lese URL-er, sette informasjonskapsler, sjekke DNS/TLS eller endre serverkonfigurasjoner.

Slik evalueres faktiske svar og forhåndskontroller

Når du tester en CORS-policy, må du skille mellom to typer svar i inndatavalget Svar på sjekk:

• Faktisk respons: Brukes for å sjekke om nettleserkoden kan lese selve innholdet i et spesifikt svar.
• Preflight-respons: Brukes for å sjekke om en OPTIONS-forespørsel godkjenner en senere HTTP-metode og dens forespurte overskriftsnavn.

For preflight-responser er HTTP-statuskoden avgjørende. Hvis du limer inn statuslinjen sammen med hodefeltene, vil verktøyet verifisere om statusen er en vellykket 2xx-status. Hvis ingen HTTP-statuslinje er limt inn, vil resultatet for preflight-sjekken bli markert som ubestemt.

Rollen til Access-Control-Allow-Origin

Hovedoverskriften i enhver CORS-evaluering er Access-Control-Allow-Origin. Nettleseren sammenligner verdien i dette feltet med forespørselens opprinnelse. Følgende regler gjelder for denne evalueringen:

• Eksakt samsvar: Verdien må samsvare nøyaktig med verdien i Be om opprinnelse (for eksempel https://app.example.com).
• Jokertegn: Verdien * tillater enhver opprinnelse, forutsatt at forespørselen ikke inkluderer legitimasjon.
• Flere verdier: Hvis Access-Control-Allow-Origin inneholder flere verdier eller er kommaseparert, anses hodefeltet som ugyldig.

Håndtering av legitimasjon og Access-Control-Allow-Credentials

Når forespørselen inkluderer legitimasjon, som informasjonskapsler eller HTTP-autentisering, skjerpes sikkerhetsreglene i nettleseren betydelig:

1. Eksakt opprinnelse kreves: Access-Control-Allow-Origin kan ikke være et jokertegn (*) når legitimasjon er inkludert. Den må samsvare nøyaktig med forespørselens opprinnelse.
2. Eksplisitt godkjenning: Overskriften Access-Control-Allow-Credentials må være nøyaktig true. Hvis denne mangler eller har en annen verdi, blokkeres forespørselen.
3. Tap av jokertegnbetydning: Når legitimasjon er inkludert, mister jokertegn (*) sin funksjon i både Access-Control-Allow-Methods og Access-Control-Allow-Headers. De tolkes da bokstavelig i stedet for å fungere som tillatelse for alle metoder eller hoder.

Metoder og forespørselshoder i preflight-forespørsler

For preflight-forespørsler må nettleseren godkjenne både HTTP-metoden og eventuelle tilpassede hoder før den faktiske forespørselen kan sendes.

Metodegodkjenning

Nettleseren sjekker om den forespurte metoden er tillatt. Enkelte metoder er CORS-sikrede og trenger ikke å være oppført i Access-Control-Allow-Methods. Andre metoder må godkjennes eksplisitt av serveren, enten via en liste eller ved bruk av jokertegnet * (så lenge forespørselen er uten legitimasjon). Visse metoder er i tillegg blokkert av nettleseren selv i fetch-forespørsler.

Godkjenning av forespørselshoder

Overskrifter som sendes i Access-Control-Request-Headers må godkjennes av serverens Access-Control-Allow-Headers.

Spesialtilfellet Authorization krever ekstra oppmerksomhet. Selv om serveren returnerer Access-Control-Allow-Headers: *, dekker ikke dette jokertegnet Authorization-hodet. Authorization må alltid være eksplisitt oppført i listen over tillatte hoder.

Begrensninger ved statisk analyse

Dette verktøyet utfører en regelbasert analyse av de oppgitte tekststrengene. Et bestått resultat betyr utelukkende at de innsendte hodefeltene og forespørselsdetaljene oppfyller nettleserens CORS-spesifikasjoner. Analysen kan ikke ta høyde for eksterne faktorer som omdirigeringer, hurtigbufrede svar på nettverkssiden, endringer i serverens regler over tid, aktive nettleserutvidelser eller avvik i den faktiske responsen som returneres etter at en preflight-forespørsel har passert.

Personvern og databehandling

Når du bruker dette verktøyet, forblir alle overskrifter og forespørselsdetaljer lokalt i nettleseren din. Ingenting blir lastet opp til eller lagret av BroBroGo.

Ofte stilte spørsmål (FAQ)

Bør jeg lime inn det faktiske svaret eller forhåndskontrollsvaret?
Bruk Faktisk svar for å sjekke om nettleserkoden kan lese ett svar. Bruk forhåndskontrollsvar for OPTIONS-svaret som godkjenner en senere metode og dens forespurte overskriftsnavn.

Hvorfor kan et jokertegn mislykkes med legitimasjon?
Når informasjonskapsler eller HTTP-autentisering er inkludert, må den tillatte opprinnelsen samsvare nøyaktig med opprinnelsen som ber om. Jokertegn for tillatte metoder og overskrifter mister også betydningen av jokertegn.

Beviser et bestått resultat at direkteforespørselen vil fungere?
Nei. Dette resultatet dekker bare det innlimte svaret og forespørselsdetaljene som er lagt inn her. Omdirigeringer, hurtigbufrede svar, endring av serverregler, nettleserutvidelser og den faktiske responsen etter en forhåndskontroll kan fortsatt endre utfallet.

*Hvorfor blir Authorization-hodet blokkert selv om Access-Control-Allow-Headers er satt til ?
Nettleserens CORS-spesifikasjon krever at Authorization-hodet må være oppført eksplisitt i Access-Control-Allow-Headers. Jokertegnet * er ikke tilstrekkelig for å dekke dette spesifikke hodefeltet.