Hva er en preflight-request?

Nettleseren sender en OPTIONS-forespørsel før den «egentlige» for å spørre serveren om metoden og headerne dine er tillatt. Preflight utløses av alle ikke-«simple» requests: PUT, DELETE, PATCH, egendefinerte headere, Content-Type utenom form-urlencoded/multipart/plain.

Kan jeg gå rundt CORS?

Ikke fra nettleseren, det er en sikkerhetsfunksjon som beskytter brukeren mot skadelige nettsteder. Fra en server (backend) er det ingen CORS-restriksjoner, du kan lage en enkel proxy-endepunkt som frontend kaller. Aldri deaktiver CORS-sjekk via nettleser-flagg i produksjon.

Hvorfor virker curl men ikke fetch()?

CORS gjelder bare i nettleseren. curl, Postman og server-til-server-kall ignorerer CORS-headere fullstendig. Hvis curl virker men fetch() feiler er nesten alltid årsaken at serveren mangler Access-Control-Allow-Origin for din frontend.

Hva er «credentials»?

Cookies, HTTP-basic-auth og TLS-klientsertifikater. Hvis frontend sender med credentials (fetch med credentials: «include») må serveren returnere Access-Control-Allow-Credentials: true OG angi eksakt origin (ikke wildcard *). Ellers blokkerer nettleseren.

CORS-tester: Sjekk cross-origin tillatelser

Hvordan testen fungerer

Verktøyet sender en ekte forespørsel til URL-en med fetch() og mode «cors». Hvis nettleseren tillater svaret, er cross-origin-tilgang åpen for den metoden. Hvis den blokkeres, kaster fetch() en feil.

Merk: nettleseren skjuler selve CORS-headerne (som Access-Control-Allow-Origin) fra JavaScript av sikkerhetshensyn. Derfor utleder testen tillatelsen fra om forespørselen lykkes, framfor å lese headeren direkte. For ikke-enkle metoder (PUT/DELETE/PATCH) utløses en preflight (OPTIONS) automatisk av nettleseren.

Om dette verktøyet

CORS-testeren hjelper deg å se om et API tillater at nettleseren din snakker direkte med det fra et annet domene. CORS (Cross-Origin Resource Sharing) er sikkerhetsmekanismen som gjør at en side på example.com ikke kan lese data fra bank.no uten samtykke fra bank.no. Verktøyet sender en preflight OPTIONS-forespørsel etterfulgt av selve forespørselen, viser deg alle Access-Control-headere serveren returnerer, og forklarer hvorfor eventuell CORS-blokkering skjer. Nyttig for API-utviklere som skal konfigurere headere, og for frontend-utviklere som må diagnostisere «CORS error» i konsollen.

Slik bruker du det

Lim inn URL-en til API-endepunktet du vil teste.
Velg HTTP-metode (GET, POST, PUT osv.) og sett eventuelle egendefinerte headere.
Trykk «Test» for å sende preflight og selve forespørselen.
Les Access-Control-headere som returneres og eventuelle feilmeldinger.

Eksempler

Åpent API

InnGET https://api.example.com/v1/users

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Status: 200 OK (tillatt fra alle origins)

API som blokkerer

InnPOST https://api.privat.no/checkout

(preflight svarer 200, men Access-Control-Allow-Origin mangler)
Resultat: blokkert av browser, CORS-feil.

Uten Access-Control-Allow-Origin blokkerer nettleseren svaret, selv om serveren returnerte 200. Server må konfigureres til å tillate ditt origin.

Vanlige bruksområder

Verifisere at ditt API tillater kall fra frontend-domenet.
Diagnostisere «CORS error» i produksjon uten å måtte deploye ny kode.
Sjekke om tredjeparts-API-er du vurderer å bruke støtter direkte browser-kall.
Teste at nye Access-Control-headere fungerer etter server-config-endring.
Undervise juniorutviklere om hva preflight faktisk gjør.

Ofte stilte spørsmål

Hva er en preflight-request?: Nettleseren sender en OPTIONS-forespørsel før den «egentlige» for å spørre serveren om metoden og headerne dine er tillatt. Preflight utløses av alle ikke-«simple» requests: PUT, DELETE, PATCH, egendefinerte headere, Content-Type utenom form-urlencoded/multipart/plain.
Kan jeg gå rundt CORS?: Ikke fra nettleseren, det er en sikkerhetsfunksjon som beskytter brukeren mot skadelige nettsteder. Fra en server (backend) er det ingen CORS-restriksjoner, du kan lage en enkel proxy-endepunkt som frontend kaller. Aldri deaktiver CORS-sjekk via nettleser-flagg i produksjon.
Hvorfor virker curl men ikke fetch()?: CORS gjelder bare i nettleseren. curl, Postman og server-til-server-kall ignorerer CORS-headere fullstendig. Hvis curl virker men fetch() feiler er nesten alltid årsaken at serveren mangler Access-Control-Allow-Origin for din frontend.
Hva er «credentials»?: Cookies, HTTP-basic-auth og TLS-klientsertifikater. Hvis frontend sender med credentials (fetch med credentials: «include») må serveren returnere Access-Control-Allow-Credentials: true OG angi eksakt origin (ikke wildcard *). Ellers blokkerer nettleseren.

Teknisk bakgrunn

CORS er definert i Fetch-standarden (fetch.spec.whatwg.org). Den bygger på konseptet «same-origin policy»: en side kan lese svar fra samme kombinasjon av protokoll, vert og port som den ble hentet fra. Alt annet er «cross-origin» og krever eksplisitt tillatelse via Access-Control-headere. Enkle requests (GET/HEAD/POST med form-content-type) sendes rett fram, og nettleseren sjekker Access-Control-Allow-Origin i svaret før den lar JavaScript lese det. Komplekse requests utløser en preflight OPTIONS-request som spør: «Har jeg lov til å sende PATCH med Content-Type: application/json og en X-Trace-Id-header?». Serveren svarer med Allow-Methods, Allow-Headers og Max-Age (hvor lenge nettleseren kan cache preflight-svaret, typisk 600s). Vær bevisst når du bruker Allow-Origin: *: da kan du ikke bruke credentials, og alle domener på hele internett kan lese svaret. Best practice for API-er er å ekko tilbake Origin-headeren fra requesten hvis den er i en whitelist, sammen med Access-Control-Allow-Credentials: true bare hvis auth trengs.