Cross-Origin Resource Sharing (CORS)

Även om SOP är bra för säkerheten skapar den problem för moderna webbarkitekturer.

Många applikationer, särskilt SPA:er, behöver hämta data från API:er som finns på en annan domän eller port. Exempelvis:

• Din SPA finns på https://my-app.com
• Ditt API finns på https://api.my-app.com
• Din OAuth2 Authorization Server finns på https://auth.my-app.com

CORS ger ett kontrollerat sätt att lätta på SOP och tillåta dessa förfrågningar mellan olika ursprung, samtidigt som säkerheten bevaras.

Vissa förfrågningar mellan olika ursprung betraktas som ”enkla” av webbläsare. De utlöser ingen särskild preflight-kontroll.

En förfrågan är enkel om den uppfyller alla dessa villkor:

• Metoden är GET, HEAD eller POST.
• Endast särskilt tillåtna headers används (till exempel Accept, Accept-Language, Content-Language, Content-Type).
• Headern Content-Type är begränsad till application/x-www-form-urlencoded, multipart/form-data eller text/plain.

Om förfrågan är enkel skickar webbläsaren den direkt, och servern inkluderar CORS-headers i svaret.

De flesta förfrågningar i moderna SPA:er, särskilt sådana som innehåller OAuth2-token, är inte enkla.

En ”komplex” förfrågan kräver att webbläsaren skickar en ”preflight”-förfrågan med OPTIONS innan den faktiska förfrågan:

• Metoder: PUT, DELETE eller anpassade metoder.
• Headers: Anpassade headers (till exempel Authorization för åtkomsttoken).
• Content-Type: application/json (vanligt för API:er).

Servern måste svara på denna OPTIONS-förfrågan med lämpliga CORS-headers och ange om den faktiska förfrågan är tillåten.

Servern kommunicerar sin CORS-policy genom särskilda HTTP-headers i svaret:

• Access-Control-Allow-Origin: Anger vilka ursprung som får komma åt resursen. Kan vara * (jokertecken, vilket i allmänhet avråds från av säkerhetsskäl) eller ett specifikt ursprung som https://my-app.com.
• Access-Control-Allow-Methods: Anger vilka HTTP-metoder (till exempel GET, POST, PUT, DELETE) som är tillåtna för resursen.
• Access-Control-Allow-Headers: Anger vilka HTTP-headers (till exempel Authorization, Content-Type) som får användas i den faktiska förfrågan.

Dessa headers är avgörande för att webbläsaren ska tillåta förfrågan mellan olika ursprung.

Headern Access-Control-Allow-Credentials är ytterligare en viktig CORS-header.

När den är satt till true anger den för webbläsaren att servern tillåter att cookies, HTTP-autentisering eller SSL-klientcertifikat inkluderas i förfrågan mellan olika ursprung.

I OAuth2/OIDC skickas åtkomsttoken vanligtvis i headern Authorization, inte som cookies. Om ni däremot använder sessionscookies för autentisering eller identitetshantering tillsammans med token blir denna header relevant.

CORS är viktigt på flera ställen i OAuth2/OIDC:

• Tokenutbyte: Din SPA kan behöva byta en auktoriseringskod mot en åtkomsttoken vid Authorization Servers token-endpoint. Detta är en POST-förfrågan mellan olika ursprung.
• API-åtkomst: När din SPA har en åtkomsttoken använder den den för att anropa ett Resource Servers API (till exempel GET /userinfo, POST /orders). Även detta är en förfrågan mellan olika ursprung.

Authorization Server och Resource Server måste konfigureras korrekt för att tillåta dessa förfrågningar från din SPAs ursprung.

Följ dessa riktlinjer för säkra OAuth2/OIDC-implementationer med CORS:

• Specifika ursprung: Ange alltid exakta ursprung (till exempel https://my-app.com) i Access-Control-Allow-Origin. Använd aldrig * i produktion.
• Begränsa metoder och headers: Tillåt endast de HTTP-metoder och headers som klientapplikationerna faktiskt behöver.
• Konfigurera servrar: Säkerställ att Authorization Server och Resource Server är korrekt konfigurerade för att skicka nödvändiga CORS-headers.
• Hantera preflight: Se till att servern kan svara på OPTIONS-förfrågningar för preflight-kontroller.

Felkonfigurerad CORS kan leda till säkerhetsbrister och möjliggöra obehörig åtkomst.

Ni har lärt er om Cross-Origin Resource Sharing (CORS) och dess viktiga roll för att säkra moderna webbapplikationer, särskilt sådana som använder OAuth2 och OpenID Connect.

• CORS lättar på webbläsarens Same-Origin Policy.
• Det möjliggör säker kommunikation mellan olika ursprung.
• Preflight-förfrågningar för ”komplexa” API-anrop är vanliga när OAuth2-token används.
• Korrekt konfiguration på serversidan av CORS-headers (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers) är avgörande.

Följ alltid bästa praxis för att förhindra felkonfigurationer som kan exponera era skyddade resurser.