Den komplette guide til websikkerhed: CORS, CSP og HSTS

1. CORS (Cross-Origin Resource Sharing): Sikring af dine API’er

For at forstå CORS skal du først forstå Same-Origin Policy (SOP). Som standard begrænser webbrowsere websider fra at sende anmodninger til et andet domæne (origin) end det, der leverede websiden. For eksempel kan et script på https://myblog.com ikke vilkårligt hente private data fra https://api.mybank.com. Dette er en kritisk indbygget forsvarsmekanisme.

Moderne globale applikationer er dog stærkt decentraliserede. Din frontend kan være hostet på Vercel, dit API på AWS og dine billeder på Cloudflare. CORS er den protokol, der gør det muligt for dig sikkert at omgå SOP. Den bruger specialiserede HTTP-headere til at fortælle browseren: »Det er okay, at dette specifikke eksterne domæne får adgang til mine ressourcer.«

• Preflight-anmodningen: Ved komplekse anmodninger (som at sende JSON-data via POST eller PUT) sender browseren først en usynlig OPTIONS-anmodning (»preflight«) for at spørge serveren, om den egentlige anmodning er tilladt. Hvis serveren godkender den, sendes den reelle anmodning.
• Den fatale fejl: Mange udviklere bliver frustrerede over CORS-fejl og sætter simpelthen Access-Control-Allow-Origin: * (jokertegnet). Dette er en katastrofal sikkerhedssvaghed, da det giver bogstaveligt talt enhver hjemmeside på internettet mulighed for at forespørge dit API. Angiv altid præcise, betroede origins.

2. CSP (Content Security Policy): Det ultimative skjold mod XSS

Cross-Site Scripting (XSS) er en af de mest almindelige og farlige sårbarheder på nettet. Den opstår, når en hacker formår at injicere skadelig JavaScript på din side (f.eks. via en sårbar kommentarsektion). Når en bruger besøger siden, eksekverer det skadelige script, stjæler deres session-cookies eller omdirigerer dem til en phishing-side.

CSP fungerer som en utrolig striks dørmand for din webside. Det er en HTTP-header, der gør det muligt for siteadministratorer at deklarere en godkendt »hvidliste« over dynamiske ressourcer, der har tilladelse til at blive indlæst. Hvis et script forsøger at eksekvere, men dets origin ikke er på hvidlisten, blokerer browseren det simpelthen.

3. HSTS (HTTP Strict Transport Security): Tvinger den sikre rute

Du har installeret et SSL/TLS-certifikat, og din side indlæses over HTTPS. Du er sikker, ikke? Ikke helt. Når en bruger manuelt indtaster yourdomain.com i deres browser, defaulter den indledende anmodning ofte til den ukrypterede http://-protokol. I det splitsekund, før din server omdirigerer dem til https://, kan en hacker, der befinder sig på det samme offentlige Wi-Fi-netværk, udføre et Man-In-The-Middle (MITM) SSL Stripping-angreb, der opsnapper trafikken.

HSTS eliminerer fuldstændigt dette sårbarhedsvindue. Når en server sender HSTS-headeren, udsteder den en striks kommando til browseren: »I de næste X tidsenheder må du aldrig, aldrig forsøge at indlæse denne side via HTTP. Gennemtving HTTPS internt, allerede før anmodningen forlader enheden.« Derudover kan du indsende dit domæne til den globale HSTS Preload List, som er hardkodet i Chrome, Firefox og Safari, hvilket sikrer, at brugere forbinder sikkert selv ved deres allerførste besøg.

4. Implementering: Serverkonfigurationsuddrag

Implementering af disse politikker kræver ændring af din serverkonfiguration. Her er et produktionsklart uddrag til Nginx, der opsætter striks CORS, en robust CSP og maksimal-sikkerheds-HSTS.

server {
    listen 443 ssl http2;
    server_name www.yourglobaldomain.com;

    # 1. HSTS-konfiguration
    # Gennemtving HTTPS i 1 år (31536000 sekunder), inkludér subdomæner, og tillad preloading
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # 2. CSP (Content Security Policy)-konfiguration
    # Tillad kun scripts fra dit domæne og Google Analytics. Tillad ikke inline-scripts.
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline';" always;

    # 3. CORS-konfiguration (til en API-blok)
    location /api/ {
        # Brug ALDRIG '*' i produktion. Angiv præcise, betroede frontend-domæner.
        add_header 'Access-Control-Allow-Origin' 'https://www.yourfrontend.com' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;

        # Håndter preflight-anmodninger
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' 'https://www.yourfrontend.com';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }
    }
}

Konklusion: Sikkerhed er SEO

I det moderne web-økosystem er sikkerhed og SEO dybt sammenflettede. Google bruger eksplicit HTTPS som et rangeringssignal, og deres algoritmer er meget følsomme over for brugersikkerhedsmetrikker. Ved korrekt at implementere CORS, CSP og HSTS beskytter du ikke blot dine brugeres data—du opbygger et robust, yderst troværdigt digitalt aktiv, som søgemaskiner med tillid vil anbefale til globale målgrupper. Gennemgå dine HTTP-headere i dag, og luk dørene for skadelige aktører.

Nøgleord: #WebSecurity #CORS #ContentSecurityPolicy #HSTS #CyberSecurity #GlobalSEO #HTTPS #TechStandards