Hantering av CORS i webbapplikationer

0
246
Shutterstock/Gorodenkoff

CORS är en webbläsarmekanism som låter servrar ange det tredje parts ursprung som kan begära resurser från dem. Det är ett säkerhetsskydd som hjälper till att hindra skadliga webbplatser från att stjäla data som ägs av andra ursprung.

CORS står för Cross-Origin Resource Sharing. När CORS används för att ladda en resurs skickar webbläsaren vanligtvis ett & # 8220; preflight & # 8221; HTTP OPTIONS-begäran. Servern måste svara och ange ursprunget som den kommer att interagera med. Det kan också definiera ytterligare begränsningar, till exempel HTTP-rubriker som kan skickas.

Webbläsaren kontrollerar det aktuella ursprunget och den utgående begäran mot servers specifikationer. Begäran får fortsätta om alla kontroller passerar. Annars kommer den ursprungliga begäran att annulleras. Du ser en varning i konsolen när detta händer.

När CORS används

Webbläsare verkställer CORS för Ajax och Fetch-begäranden. Mekanismen kommer också att användas för webbfonter, WebGL-texturer och ritningar av dukbilder med drawImage (). Varje berättigad begäran till tredje parts ursprung kräver att CORS-utbyte äger rum.

CORS kommer inte att verkställas om begäran ses som & # 8220; enkel & # 8221; En enkel begäran måste vara GET, HEAD eller POST med en innehållstyp text/vanlig, applikation/x-www-form-urlencoded eller multipart/form-data. De enda tillåtna enkla förfrågningsrubrikerna är Accept, Accept-Language, Content-Language och Content-Type.

Om begäran inte uppfyller alla ovanstående kriterier kommer ett CORS-utbyte att inledas av moderna webbläsare. Det är viktigt att känna igen CORS är en webbläsarbaserad teknik & # 8211; du kommer aldrig att stöta på CORS när du gör förfrågningar manuellt, till exempel med curl i din terminal.

CORS-utbyten skickar inte alltid en förfrågning om OPTIONS preflight. En preflight används när begäran skulle orsaka & # 8220; biverkningar & # 8221; på servern. Detta är i allmänhet fallet för andra förfrågningsmetoder än GET.

Föreställ dig en POST-begäran till/api/användare/skapa. Servern skulle alltid skapa en ny användare men webbläsaren kan vägra åtkomst till svaret om begäran var föremål för CORS. Genom att skicka en OPTIONS-begäran först har servern en chans att uttryckligen avslå den verkliga begäran. Detta säkerställer att användarkontot inte faktiskt skapas.

Hantering av CORS-klientsidan

Även om CORS är en webbläsarteknik kan du inte direkt påverka den med klientsides-kod. Detta förhindrar skadliga skript från sido-steg-CORS-skydd för att ladda data från tredjepartsdomäner.

CORS är vanligtvis transparent så du kommer inte att vara medveten om att den är i drift. Om ett CORS-utbyte misslyckas visas en generisk nätverksfel i din JavaScript-kod. Det är inte möjligt att få exakta detaljer om vad som gick fel, eftersom detta skulle vara en säkerhetsrisk. De fullständiga detaljerna loggas till konsolen.

Det enda sättet att lösa ett CORS-fel är att se till att din server skickar rätt svarsrubriker. Låt oss nu titta på hur det görs.

Hantering av CORS-serversidan

Du bör först se till att din server hanterar OPTIONS-förfrågningar korrekt. Du kan behöva skapa en ny rutt i ditt webbramverk. Du kommer i allmänhet att behöva acceptera OPTIONS-förfrågningar till varje slutpunkt som kan få en förfrågan från en webbläsare. Svaret behöver inte ha en kropp utan måste innehålla specifika rubriker som informerar webbläsaren om hur man ska fortsätta.

Börja med att lägga till rubriken Access-Control-Allow-Origin. Detta anger det tredje parts ursprung som får kommunicera med din slutpunkt. Endast ett ursprung kan anges; du kan hantera flera ursprung genom att dynamiskt ställa in huvudets värde till det ursprung begäran skickades från. Du kan hämta det aktuella ursprunget från rubriken för begäran om ursprung.

Access-Control-Allow-Origin accepterar * som ett speciellt jokerteckenvärde. Detta gör det möjligt för CORS-förfrågningar från alla ursprung. Var försiktig när du använder detta & # 8211; att vara specifik med det tillåtna ursprunget ger dig mer kontroll och förhindrar att skadliga skript begär data från din server.

Access-Control-Allow-Origin måste inkluderas i din servers svar på den verkliga förfrågan, liksom OPTIONS-svaret. När den här enskilda rubriken har konfigurerats tillåts ett grundläggande utbyte med en webbläsarklient från tredje part.

Specifying Cross-Origin Headers

CORS-förfrågningar stöder vanligtvis bara & # 8220; enkel & # 8221; begär rubriker som anges ovan. Om du behöver använda något annat sidhuvud, till exempel Auktorisering eller ett anpassat sidhuvud, måste din server uttryckligen tillåta det i preflight-svaret.

Ställ in rubriken Access-Control-Allow-Headers. Dess värde bör vara en kommaseparerad lista med rubriknamn som accepteras med den verkliga begäran.

Access-Control-Allow-Headers: Authorization, X-Custom-Header

Webbläsaren tillåter nu en begäran med antingen Authorization eller X-Custom-Header-rubriker att fortsätta.

När webbläsaren skickar en CORS preflight-begäran skickar den rubriken Access-Control-Request-Headers. Detta innehåller listan med rubriker som skickas med den faktiska begäran. Din serverkod kan använda den här informationen när du bestämmer hur du ska svara på begäran om preflight.

Begränsning till specifika förfrågningsmetoder

På samma sätt som för att specificera förfrågningsrubriker kan serverns slutpunkter definiera vilka HTTP-metoder som ska tillåtas korsor. Ställ in rubriken Access-Control-Allow-Methods som en kommaseparerad lista med metodnamn.

Access-Control-Allow-Methods: GET, POST, DELETE

Webbläsaren skickar Access-Control-Request- Metodrubrik med CORS-förflygningar. Detta låter din server känna till HTTP-metoden som kommer att användas för att göra den slutliga begäran.

Cookies och referenser

CORS-begäranden skickar normalt inte cookies eftersom de kan innehålla känsliga referenser som identifierar avsändaren. Om du behöver inkludera kakor med en korsningsbegäran måste du uttryckligen aktivera detta i din klientsides kod:

fetch (“https: //localhost/demo”, {mode: “cors”, referenser: “inkludera”});

Dessutom måste servern ställa in Access-Control-Allow-Credentials: true response-rubriken för att signalera sitt samtycke att credentialled cookies kan utbytas.

När du använder Access-Control-Allow-Credentials är du kan inte använda jokertecken (*) med Access-Control-Allow-Origin. Servern måste istället ange ett uttryckligt ursprung för att skydda användarnas integritet. Om jokertecknet skickas misslyckas webbläsaren med begäran med ett CORS-fel.

Preflight Caching

CORS ALTERNATIV förflygningar lägger till en overhead till varje begäran du gör. Även om förseningen knappt skulle kunna märkas av en bra nätverksanslutning är det ändå slösaktigt när du ringer samma slutpunkt flera gånger i snabb följd.

Du kan be webbläsaren att cache preflight-svar genom att ställa in rubriken Access-Control-Max-Age. Värdet ska vara den tid i sekunder som webbläsaren får cache-svaret för. Efterföljande förfrågningar till samma slutpunkt inom den angivna perioden skickar inte ett CORS-preflight.

Slutsats

CORS kan verka förvirrande första gången du stöter på det. Det är en webbläsarteknik som styrs av serversvar. CORS är oundvikligt och ändå okontrollerbart, såvida du inte har tillgång till koden på serversidan som du interagerar med.

Den faktiska implementeringen av CORS är ganska enkel. Se till att ditt API eller CDN skickar rätt svarsrubriker, särskilt Access-Control-Allow-Origin. Du kommer då att ha säker kommunikation med ursprung som hjälper dig att skydda dig mot dåliga skådespelare.