Säkerhetsheaders för småföretag — HTTPS, HSTS och CSP förklarat | Siteflow

De flesta som driver en hemsida vet att de behöver HTTPS. Färre vet att HTTPS bara är en bit av pusslet. Det finns en handfull osynliga HTTP-headers som din server skickar tillsammans med varje sida — och om de saknas är din sajt sårbar för attacker som clickjacking, XSS och man-in-the-middle. Headersarna är gratis att sätta, tar några minuter att konfigurera och stänger ute en hel klass av hot. Ändå saknas de på majoriteten av svenska småföretagssajter. Här är en praktisk genomgång.

Vad säkerhets headers faktiskt är

När en webbläsare laddar din hemsida skickar servern först en uppsättning HTTP-headers — metadata om svaret. Bland dessa kan du lägga till instruktioner till webbläsaren om hur den ska behandla sidan: tvinga HTTPS, blockera okända skript, vägra att låta sajten visas i en iframe, och så vidare.

Tanken är enkel: webbläsaren följer reglerna du sätter. Sätter du inga regler tillämpas de mest tillåtande standardvärdena — och det är där säkerhetshålen uppstår.

Du kan när som helst testa vilka headers din sajt skickar med Siteflows gratis säkerhetstest — det tar 10 sekunder och du får en lista över vad som saknas.

De sex headers du behöver känna till

Strict-Transport-Security (HSTS) — tvingar HTTPS

HSTS säger till webbläsaren: "nästa gång du besöker den här domänen, använd HTTPS direkt — fråga inte ens, gå inte ens via HTTP först". Effekten är att även om en angripare försöker omdirigera trafik via en falsk WiFi (man-in-the-middle), kommer webbläsaren vägra prata HTTP med din domän.

Konkret värde:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age är hur länge regeln gäller (här ett år i sekunder), includeSubDomains täcker alla subdomäner, och preload låter dig anmäla domänen till Chromes och Firefox inbyggda HSTS-lista — då gäller HSTS redan vid första besöket.

Content-Security-Policy (CSP) — skydd mot XSS

CSP är den mäktigaste och den krångligaste headern. Den definierar vitt på vitt vilka källor som får leverera skript, stilar, bilder och iframes till din sida. Om en angripare lyckas injicera ett <script>-tag via ett kommentarsfält eller en sårbar plugin, vägrar webbläsaren köra det — för det kommer inte från en godkänd källa.

Detta är ditt huvudförsvar mot cross-site scripting (XSS), den vanligaste klassen av webbattacker.

Ett enkelt exempel för en WordPress-sajt som använder Google Fonts och Google Analytics:

Content-Security-Policy: default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'none';

Varningen: CSP är lätt att konfigurera fel. Sätter du den för strikt slutar din egen sajt fungera. Sätter du den för slappt skyddar den inget. Det är därför vi rekommenderar att börja i Content-Security-Policy-Report-Only-läge, samla in vad som bryter, och först sedan aktivera skarp policy.

X-Frame-Options — stopp för clickjacking

Clickjacking är när en angripare embeddar din sajt i en osynlig iframe på sin egen sida, lägger en knapp ovanpå, och lurar besökaren att klicka på något helt annat än vad de tror.

X-Frame-Options: DENY säger till webbläsaren att din sajt aldrig får visas inuti en iframe. För moderna webbläsare räcker frame-ancestors 'none' i CSP — men headern är fortfarande kvar för äldre klienters skull.

X-Content-Type-Options — nosniff

X-Content-Type-Options: nosniff

Den här raden hindrar webbläsaren från att "gissa" vilken filtyp en uppladdad fil är. Utan den kan en angripare ladda upp en bildfil som egentligen innehåller JavaScript, och webbläsaren kör den som skript. Det är en enradare som stänger en hel attackvektor.

Referrer-Policy — kontroll över vad du läcker

När en besökare klickar från din sajt till en extern länk skickar webbläsaren normalt med URL:en de kom från. Det kan läcka känslig information — interna sökresultat, kundnummer i URL:er, lösenordsåterställningstoken.

Rekommenderat värde för de flesta sajter:

Referrer-Policy: strict-origin-when-cross-origin

Externa sajter ser då bara din domän, inte den exakta sidan.

Permissions-Policy — stäng av oanvända features

Webbläsare har dussintals API:er — kamera, mikrofon, geolocation, betalningar, USB. De flesta sajter behöver inget av detta. Permissions-Policy låter dig stänga av allt du inte använder, så att en eventuellt komprometterad sida inte kan begära åtkomst till besökarens kamera.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Hoten dessa headers stoppar

Det är lätt att avfärda säkerhets headers som teoretiska. De är inte det. Konkret skyddar de mot:

Clickjacking. Din sajt embeds i en angriparkontrollerad iframe. Besökaren tror de klickar på "Spela" — i själva verket klickar de "Godkänn att överföra pengar". X-Frame-Options stoppar det.

Man-in-the-middle (MITM). Besökare på öppet WiFi omdirigeras via en proxy som degraderar HTTPS till HTTP och snokar lösenord. HSTS gör att webbläsaren vägrar prata HTTP med din domän.

XSS (cross-site scripting). En sårbar kommentarsmodul, ett bristfälligt sökfält eller en kapad plugin laddar in skadlig JavaScript som stjäl kakor, sessioner eller dataformulär. CSP är den enda riktigt effektiva försvarslinjen mot detta.

MIME-sniffing-attacker. Angripare laddar upp filer som ser ut som bilder men innehåller skript. X-Content-Type-Options stoppar webbläsaren från att exekvera dem.

Referrer-läckage. Interna URL:er, sökfraser och token läcker till tredjepartssajter via Referer-headern. Referrer-Policy stoppar det.

Hur du sätter dem på olika plattformar

WordPress. Du har två val. Antingen redigerar du .htaccess (Apache) eller nginx.conf direkt — då lägger du till Header set-rader för varje header. Eller så installerar du en plugin som Really Simple SSL Pro eller HTTP Headers som ger dig ett gränssnitt. Plugin-varianten är säkrare för icke-tekniska användare men lägger till ännu en plugin att underhålla.

Squarespace. Inget officiellt stöd för att sätta egna säkerhets headers. Plattformen sätter HSTS men inte CSP eller Permissions-Policy. Det är en av flera anledningar till att Squarespace inte räcker för säkerhetsmedvetna verksamheter.

Wix. Liknande situation som Squarespace — du kan inte sätta egna headers. HSTS sätts av plattformen, resten saknas.

Webflow. Begränsat stöd. Du kan sätta vissa headers via deras hostingpanel men inte alla — CSP är till exempel inte fullt konfigurerbar.

Siteflow. Alla rekommenderade säkerhets headers — HSTS med preload, CSP anpassad för din sajt, X-Frame-Options, X-Content-Type-Options, Referrer-Policy och Permissions-Policy — sätts automatiskt på alla paket. Inga plugins, ingen .htaccess att redigera, ingen risk att glömma. Vi testar varje sajt vi levererar mot vårt säkerhetstest innan den går live.

Hur du testar din egen sajt

Det enklaste sättet att se var du står är att köra din domän genom Siteflows säkerhetstest. Du får på 10 sekunder en betygsatt rapport över vilka headers som är på plats, vilka som saknas och vilken risk det utgör.

Andra etablerade verktyg är Mozillas Observatory och securityheaders.com — bägge ger en bokstavsbetyg från A+ till F.

Det viktiga är inte att få A+ på första försöket. Det viktiga är att du vet vad som saknas och successivt fyller i — HSTS först (lättast), sedan X-Frame-Options och nosniff (också enkelt), och slutligen CSP (kräver mest jobb).

Sammanfattning

Säkerhets headers är gratis, snabba att sätta och stoppar en hel klass av attacker. Om du driver en WordPress-sajt med en kontaktformulär och e-postlista är CSP och HSTS det enklaste sättet att höja säkerhetsnivån utan att byta plattform. Om du säljer något online — där läckta kakor eller kapade sessioner kan kosta riktigt — är de inte valbara längre.

Och om du inte vill mecka med .htaccess och CSP-direktiv själv: Siteflow sätter alla säkerhets headers automatiskt på varje hemsida vi levererar. Det är inte en tilläggstjänst — det är en del av att leverera en hemsida som inte läcker.

FAQ

Behöver en liten företagshemsida verkligen CSP? Om du har en kontaktformulär eller laddar tredjepartsskript som Google Analytics — ja. CSP är ditt enda effektiva försvar mot XSS, och XSS är inte ett "stora bolag"-problem.

Kan jag skada min sajt genom att sätta fel headers? Ja, särskilt CSP. Sätt först Content-Security-Policy-Report-Only, samla in vad som bryter i webbläsarkonsolen, justera och först sedan aktivera skarp policy.

Räcker det med HSTS om jag redan har HTTPS? HTTPS skyddar pågående trafik. HSTS skyddar mot att en angripare degraderar en framtida besökares anslutning till HTTP. Du behöver båda.

Hur ofta ska jag granska mina headers? Vid varje större ändring — ny plugin, nytt tredjepartsverktyg, ny domän. Annars en gång i kvartalet. Kör säkerhetstestet och se om något har förändrats.

Är det här relevant för en ren statisk hemsida utan inloggning? Mindre kritiskt än för en e-handel, men fortfarande relevant. Clickjacking och MIME-sniffing fungerar även mot statiska sajter — och kostnaden att sätta headers är noll.

Relaterade artiklar

• Cookies och GDPR 2026 — vad cookies är, när du måste ha en banner och vad det kostar att göra fel.
• Säkerhetstest för hemsidan — gratis verktyg som kontrollerar HSTS, CSP och övriga headers på din sajt.
• Siteflow-paket — hemsidor med säkerhets headers, HTTPS och uppdateringar inbakat från dag ett.