X-Frame-Options: vad headern gör och hur du konfigurerar den rätt

X-Frame-Options är en HTTP-svarsheader som talar om för webbläsaren om din sida får visas inuti en frame eller iframe på en annan webbplats. Den har exakt två giltiga värden: DENY (ingen inbäddning alls) och SAMEORIGIN (inbäddning tillåts bara från samma origin). Syftet är att stoppa clickjacking (klickkapning), en attack där din sajt laddas osynligt inuti angriparens sida och besökarna luras att klicka på saker de inte ser. Den moderna ersättaren är Content-Security-Policy-direktivet frame-ancestors, och bästa praxis 2026 är att skicka båda headrarna. Den här guiden visar rätt konfiguration för alla större servrar, plus misstagen som tyst slår av skyddet.

Vad X-Frame-Options gör

När en webbläsare laddar en sida som ett annat dokument har bäddat in via <iframe>, <frame>, <embed> eller <object> kontrollerar den svarsheadrarna på den inbäddade sidan innan den ritas upp. Om svaret innehåller X-Frame-Options: DENY vägrar webbläsaren att visa sidan inuti det inbäddande dokumentet. Med SAMEORIGIN visas sidan bara om hela inbäddningskedjan kommer från samma origin (samma schema, värdnamn och port). Moderna webbläsare utvärderar hela kedjan av föräldraramar, inte bara toppfönstret.

Headern formaliserades i RFC 7034 i oktober 2013, efter att webbläsarna redan hade infört den. Den är fortfarande en av webbens mest spridda säkerhetsheaders: HTTP Archives Web Almanac 2025, säkerhetskapitlet, uppmäter X-Frame-Options på ungefär 35 % av mobilsajterna, vilket gör den till en av de tre vanligaste säkerhetsheadrarna efter X-Content-Type-Options (nära 50 %).

Clickjacking på 60 sekunder

Begreppet clickjacking myntades av säkerhetsforskarna Robert Hansen och Jeremiah Grossman 2008. Attacken är enkel: angriparens sida laddar din sajt i en iframe, gör den helt genomskinlig med CSS och placerar den ovanpå harmlösa knappar. Besökaren tror sig klicka på "Spela upp video", men klicket landar i själva verket på din sajts "Radera konto", "Bekräfta betalning" eller "Godkänn app", med offrets inloggade session. OWASP dokumenterar varianter från Facebook-"likejacking" till kapade engångsköp.

Skyddet är att kontrollera inbäddningen. Om webbläsaren vägrar rendera din sida i angriparens ram faller hela överläggstricket.

De två giltiga värdena, och de du ska undvika

Det farliga är hur webbläsare hanterar ogiltiga värden: de ignorerar hela headern. En sajt som skickar ALLOW-FROM eller ALLOWALL tror sig vara skyddad medan webbläsarna behandlar den som om ingen header alls fanns. Som Web Almanac 2025 uttrycker det kan dessa värden ha satts av utvecklare som förväntade sig att skyddet var aktivt just för att headern fanns där.

Vad verklig data visar

Över de miljontals sajter som HTTP Archive mätte 2025 fördelar sig headerns värden så här:

Källa: HTTP Archive Web Almanac 2025, säkerhetskapitlet, figur 9.30 (mobildata).

Ungefär 72,1 % av sajterna som skickar headern väljer SAMEORIGIN och 24,6 % väljer DENY. Runt 3 % skickar värden som inte gör någonting, vilket på webbens skala är hundratusentals sajter med inbillat skydd. Att kontrollera vad din server faktiskt skickar tar mindre än en minut.

X-Frame-Options mot CSP frame-ancestors

W3C:s specifikation Content Security Policy Level 2 (W3C-rekommendation sedan december 2016) införde direktivet frame-ancestors och gjorde formellt X-Frame-Options föråldrad. Där XFO är en trubbig av/på-knapp är frame-ancestors en komplett tillåtlista:

Två detaljer värda att känna till. För det första påpekar MDN att frame-ancestors inte ärver från default-src: policyn default-src 'none' tillåter fortfarande vem som helst att rama in sidan, så direktivet måste anges uttryckligen. För det andra stöder alla aktuella versioner av Chrome, Edge, Firefox och Safari frame-ancestors, så det enda skälet att fortsätta skicka X-Frame-Options är djupförsvar för mycket gamla klienter. Det kostar en rad, så behåll den.

Så konfigurerar du headern på din server

Skicka headern på varje HTML-svar, exakt en gång. Exemplen nedan sätter SAMEORIGIN plus motsvarande CSP-direktiv.

nginx (i server eller location):

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache 2.4 (httpd.conf eller .htaccess, med mod_headers):

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

IIS (web.config):

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Content-Security-Policy" value="frame-ancestors 'self';" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Node.js med Express och Helmet:

const helmet = require("helmet");
app.use(helmet.frameguard({ action: "sameorigin" }));
app.use(helmet.contentSecurityPolicy({
  directives: { frameAncestors: ["'self'"] }
}));

Bakom ett CDN som Cloudflare kan du också lägga till båda headrarna med en response header-regel, vilket är praktiskt när du inte kommer åt ursprungsservern. Om en partnersajt legitimt behöver bädda in dig, lämna XFO på SAMEORIGIN och uttryck tillåtlistan i CSP: frame-ancestors 'self' https://partner.exempel.se.

Misstag som tyst slår av skyddet

• Att använda ALLOW-FROM 2026. Alla aktuella webbläsare ignorerar det, och därmed hela headern.
• Att sätta headern i en meta-tagg. X-Frame-Options fungerar bara som riktig HTTP-header, och frame-ancestors är uttryckligen förbjudet i <meta http-equiv="Content-Security-Policy">. Båda måste komma från servern.
• Att skicka headern två gånger. Dubbletter eller kommaseparerade värden som SAMEORIGIN, SAMEORIGIN (0,28 % av sajterna i Almanac 2025) kan avvisas som ogiltiga. Sätt den på ett ställe, antingen i appen eller i webbservern, inte båda.
• Att använda DENY på sidor du själv bäddar in. Om din egen kassa, widget eller förhandsvisning körs i en iframe bryter DENY den. Använd SAMEORIGIN eller en uttrycklig frame-ancestors-lista.
• Att anta att default-src täcker inbäddning. Det gör den inte. Ange frame-ancestors uttryckligen.

Så testar du din konfiguration

Öppna webbläsarens utvecklarverktyg, ladda sidan och granska svarsheadrarna på huvuddokumentet: du ska se exakt en X-Frame-Options och en Content-Security-Policy som innehåller frame-ancestors. För helhetsbilden kontrollerar den kostnadsfria FortifyNet-skanningen ditt inbäddningsskydd tillsammans med resten av dina säkerhetsheaders, SSL/TLS, DNS och e-postautentisering på cirka 60 sekunder, och talar om exakt vilken header du ska lägga till var. Ingen registrering krävs.

Relaterade guider

• HTTP Säkerhetsheaders: den kompletta guiden
• Vad är HSTS? HTTP Strict Transport Security förklarat
• Säkerhetschecklista för webbplatsen: 12 viktiga steg

Vanliga frågor

Är X-Frame-Options utfasad? Formellt ja: W3C CSP Level 2 gjorde den föråldrad till förmån för frame-ancestors redan 2016. I praktiken respekterar alla webbläsare den fortfarande, och OWASP rekommenderar att båda headrarna skickas som djupförsvar. Det enda du absolut inte ska göra är att förlita dig på ALLOW-FROM.

Ska jag välja DENY eller SAMEORIGIN? Välj DENY om inget på din sajt någonsin visas i en ram, det är det starkaste läget. Välj SAMEORIGIN om dina egna sidor bäddar in varandra, till exempel dashboards, förhandsvisningar eller interna widgetar. I Web Almanac 2025 väljer 72,1 % av sajterna SAMEORIGIN.

Hur tillåter jag att en specifik partnersajt bäddar in mina sidor? X-Frame-Options klarar inte det längre. Använd Content-Security-Policy: frame-ancestors 'self' https://partner.exempel.se och lista varje tillåten origin uttryckligen.

Vad händer om jag skickar både X-Frame-Options och frame-ancestors? Webbläsare med stöd för CSP Level 2, det vill säga alla moderna, tillämpar frame-ancestors och ignorerar X-Frame-Options. Äldre klienter faller tillbaka på X-Frame-Options. Just den fallbackkedjan är skälet till att båda rekommenderas.

Kan jag sätta X-Frame-Options i en meta-tagg? Nej. Webbläsare respekterar den bara som riktig HTTP-svarsheader. Kommer du inte åt serverkonfigurationen, sätt den via hostingpanelen, CDN-regler eller applikationens middleware.