Defaults.Exposed › Åtgärder › Clickjacking-skydd (X-Frame-Options)

Hur du fixar Clickjacking-skydd (X-Frame-Options)

En engångsinstruktion som berättar för webbläsare att inte låta andra webbplatser tyst ladda din webbplats inuti sin egna. Utan det kan en bedragare dölja dina riktiga, inloggade sidor bakom en falsk sida och lura dina kunder att klicka på saker de aldrig menade — godkänna en betalning, ändra ett lösenord, bevilja åtkomst.

Slutsats för ditt företag: En bedragare kan osynligt omsluta din live-webbplats inuti en falsk och stjäla pengar eller kontotillgång från dina inloggade kunder — och för kunden ser det ut som om din webbplats gjorde det. Åtgärden är gratis och tar en utvecklare ungefär 15 minuter; att lämna den av är ett känt gap som både bedragare och försiktiga köpare kan se på sekunder.

Vad detta kan kosta dig

• En bedragare döljer din riktiga inloggnings- eller betalningsskärm bakom en harmlöst utseende sida och lurar en kund att 'bekräfta' en överföring eller en inställningsändring utan att inse det — kunden skyller på dig, inte angriparen.
• Ditt inloggade kontoutrymme laddas osynligt ovanpå en 'Du har vunnit — klicka för att kräva'-sida; klicket godkänner faktiskt en riktig ändring på kundens konto, och du svarar på det ilskna supporthåmtalet.
• En potentiell kunds IT-team kör en snabb säkerhetsskanning innan de skriver på, ser att din webbplats kan bäddas in av vem som helst, och flaggar det som en risk som stoppar eller dödar affären.
• Ditt varumärke blir betet i en bedrägerikampanj; kunder som fastnar minns det som 'företaget vars webbplats lät det hända'.
• En revisors eller cyberförsäkrings skanning listar saknat clickjacking-skydd som en grundläggande hygienfel — billigt att åtgärda, pinsamt att ha flaggat.

Varför det spelar roll. Det här är en gratis, engångsinställning som tar minuter att lägga till, och den stänger av en hel klass av tricks riktade mot dina inloggade kunder. I vår betygsättning är det en värd-riktiga-poäng webbsäkerhetskontroll betygsatt med hög allvarlighetsgrad, för ett saknat huvud lämnar ett känt, lätt-kontrollerat hål som bedragare automatiserar och köpare letar efter.

Vad det här är, i klartext

När någon besöker din webbplats kan deras webbläsare också instrueras att ladda din webbplats inuti en annan webbplats — som ett litet fönster inbäddat inuti en större sida. Det låter ofarligt, och ibland är det det. Men det är mekanismen bakom en attack som kallas clickjacking.

Så här fungerar tricket. En bedragare bygger sin egna sida och laddar tyst din riktiga webbplats inuti den — osynligt, gjord helt transparent. Sedan lägger de sitt eget innehåll ovanpå: en iögonfallande knapp, ett “Spela video”, ett “Kräv ditt pris”. Din kund ser angriparens sida och klickar vad som ser ut som en harmlös knapp. Men för att din riktiga webbplats sitter osynligt under deras pekare, landar klicket faktiskt på din sida — bekräftar en betalning, ändrar ett lösenord, godkänner åtkomst, accepterar en behörighet. Kunden trodde de klickade på en sak; de klickade faktiskt på en annan, på en webbplats de litar på.

Clickjacking-skydd är en kort, osynlig instruktion din webbplats skickar till varje besökares webbläsare som i praktiken säger:

“Låt inte andra webbplatser ladda mig inuti dem. Om någon försöker, vägra.”

Moderna webbläsare lyder det automatiskt. Med det påslaget fungerar tricket helt enkelt inte — den inbäddade kopian av din webbplats vägrar att ladda. Utan det är din webbplats ett fritt spel att användas som det dolda lagret i ett bedrägeri, och den kund som drabbas kommer att associera hela saken med ditt varumärke, inte angriparens.

Vad det här kan kosta dig

Det här är realistiska, vardagliga scenarion. Vi namnger aldrig ett riktigt företag; det här är illustrationer av hur gapet används.

1. Den osynliga “bekräfta.” En kund är inloggad på din kontoportal i en flik. De hamnar på en sida (från en annons, ett e-postmeddelande, ett sökresultat) som lovar något lockande och visar en stor “Fortsätt”-knapp. Under den knappen finns din riktiga “Bekräfta överföring”- eller “Ändra e-post”-kontroll, laddad från deras egna inloggade session. De klickar “Fortsätt” — och godkänner ovetande en ändring på deras faktiska konto hos dig. För dem, och för ditt supportteam, ser det ut som om de gjorde det på din webbplats.

2. Inställningshijackingen. En angripare ramar in din kontoinställningssida och lägger ett oskyldigt spel eller en undersökning ovanpå. Några klick på rätt ställen vänder tyst en inställning — lägger till angriparens e-post som en återställningsadress, beviljar en apptillåtelse eller inaktiverar en säkerhetsavisering. Kontot är nu tyst komprometterat, och ingenting verkade fel vid tillfället.

3. Affären som stannar. En större kund skickar sitt standardsäkerhetsformulär innan de skriver på. En rad frågar om din webbplats anger anti-inramningsskydd (X-Frame-Options / CSP frame-ancestors). Din IT-kontakt måste svara “nej”, och inköpet pausar medan du rusar för att åtgärda en gratis, 15-minuters inställning som nu ser ut som en röd flagga inför en köpare.

4. Varumärket-som-bete-kampanjen. Eftersom dina riktiga, betrodda sidor kan bäddas in använder en angripare din inloggning eller kassa som det övertygande lagret i en bredare phishingkampanj. Kunderna som drabbas skyller inte på den skuggige angriparen — de minns det som gången “din webbplats” lät dem bli lurade.

5. Revisionsflaggan. En försäkrares skanning, eller en revisor som granskar din säkerhetsposition, listar saknat clickjacking-skydd bland fynden. Det är ett lärobokhygienfel; att ha det flaggat signalerar att de enkla, gratis skydden inte var på plats — vilket färgar hur resten av din säkerhet bedöms.

Det gemensamma: skadan landar på en riktig, inloggad kund som gör något de inte avsåg — och det bär ditt namn, inte angriparens.

Vad det faktiskt är

När en webbläsare ber din webbplats om en sida skickar din server tillbaka sidan plus några osynliga “huvuden” — extra instruktioner som webbläsaren läser men besökaren aldrig ser. Clickjacking-skydd levereras via dessa huvuden. Det finns två, och vår kontroll godkänner om något av dem är på plats:

1. Det äldre huvudet — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Det här är den långvariga, brett stödda kontrollen. Den tar ett av två praktiska värden:

• SAMEORIGIN — din egen webbplats kan bädda in sina egna sidor, men ingen utomstående webbplats kan. Det säkra standardvalet för nästan alla.
• DENY — ingen kan bädda in dina sidor, inklusive du. Använd det här bara om din webbplats aldrig ramar in sitt eget innehåll.

2. Det moderna huvudet — Content-Security-Policy frame-ancestors:

Content-Security-Policy: frame-ancestors 'self';

Det här är den nyare, mer flexibla kontrollen och den som nuvarande standarder pekar mot. Den gör samma jobb men låter dig vara precis om vem som kan bädda in dig:

• frame-ancestors 'self' — ekvivalent med SAMEORIGIN.
• frame-ancestors 'none' — ekvivalent med DENY.
• frame-ancestors 'self' https://partner.example.com — din egen webbplats plus en namngiven, betrodd partner, och ingen annan.

Vad “bra” ser ut som

Den starkaste konfigurationen använder båda: frame-ancestors för moderna webbläsare (och för precisionen att namnge tillåtna inbäddare) och X-Frame-Options: SAMEORIGIN som fallback för äldre klienter. Vår kontroll är nöjd med endera på egen hand — men eftersom båda är gratis och tar samma få minuter, finns det ingen anledning att inte sätta båda.

En viktig detalj din utvecklare bör känna till: ett Content-Security-Policy-Report-Only-huvud verkställer ingenting — det rapporterar bara. Om du vill att clickjacking-skyddet faktiskt ska träda i kraft måste det komma från ett verkställande huvud (en normal Content-Security-Policy med frame-ancestors, eller X-Frame-Options), inte ett report-only-huvud.

Så här åtgärdar du det (gratis, ~15 minuter)

Skicka det här avsnittet till den som driver din webbplats — din IT-person, webbutvecklare eller hostingsupport. Åtgärden är gratis. Det är ett eller två svarshuvuden, eller en regel i din CDN. Det finns ingenting att köpa.

Kontrollen klarar sig när antingen ett X-Frame-Options-huvud (satt till DENY eller SAMEORIGIN) eller ett CSP frame-ancestors-direktiv är på plats. Den rekommenderade bälte-och-hängslen-konfigurationen lägger till båda.

Steg 1 — Bestäm hur strikt du vill vara

• De flesta företag: SAMEORIGIN / frame-ancestors 'self'. Din egna webbplats fortsätter fungera; utomstående blockeras.
• Om din webbplats aldrig bäddar in sina egna sidor: DENY / frame-ancestors 'none' för maximal låsning.
• Om en genuin partner måste bädda in en specifik sida: namnge dem uttryckligen med frame-ancestors 'self' https://partner.example.com; och ingen annan kommer in.

Steg 2 — Lägg till huvudena (välj din plattform)

Nginx — inuti ditt server-block:

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

Apache — se till att mod_headers är aktiverat, sedan i din virtuell värd:

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

Microsoft IIS — i web.config inuti <customHeaders>:

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

Cloudflare (eller liknande CDN): gå till Regler → Omvandlingsregler → Ändra svarshuvud, och lägg till två regler som sätter X-Frame-Options till SAMEORIGIN och Content-Security-Policy till frame-ancestors 'self'; på alla svar. Det här är den enklaste vägen om du inte har direkt serveråtkomst.

Skickar du redan en Content-Security-Policy av andra skäl? Skapa inte ett andra CSP-huvud — lägg till frame-ancestors i din befintliga policy. Två CSP-huvuden kan konflikta.

Webbplatsbyggare (Squarespace, Wix, Shopify och liknande): dessa plattformar sätter ofta anti-inramningsskydd åt dig, så du kanske redan klarar dig utan att göra något. Om vår kontroll flaggar det finns kontrollen vanligtvis i plattformens säkerhetsinställningar, eller du lägger till det på CDN:en framför webbplatsen.

Steg 3 — Ladda om och verifiera

Ladda om webbservern eller driftsätt CDN-regeln, ladda sedan din live-webbplats och kontrollera svarshuvudena — webbläsarutvecklarverktyg → Nätverksflik → klicka på sidans begäran → Svarshuvuden, eller valfritt gratis verktyg för huvudkontroll. Bekräfta att huvudet/huvudena visas på riktiga sidsvar, inte bara hemsidan. Kör sedan om kontrollen.

Vanliga misstag

• Använda en report-only CSP och anta att det skyddar dig. Content-Security-Policy-Report-Only rapporterar bara överträdelser — det verkställer ingenting. Du behöver ett verkställande huvud för att skyddet ska träda i kraft.
• Sätta två separata Content-Security-Policy-huvuden. Om du redan har en CSP, lägg till frame-ancestors i den snarare än att emittera en andra policy; konflikterande CSP-huvuden kan ge oförväntat beteende.
• Sätta DENY när din egen webbplats bäddar in sina egna sidor. DENY blockerar all inramning, inklusive din egen. Om någon del av din webbplats använder iframes av sig själv, använd SAMEORIGIN / frame-ancestors 'self' istället, annars bryter du dina egna sidor.
• Bara skydda hemsidan. De sidor som spelar mest roll för clickjacking är de inloggade — kontoinställningar, betalningsbekräftelse, admin. Se till att huvudena tillämpas webbplatsövergripande, inte bara på framsidan.
• Anta att HTTPS eller hänglåset redan täcker det. Kryptering och anti-inramning är orelaterade. Ett perfekt certifikat gör ingenting för att förhindra att dina sidor bäddas in.
• Förlita sig på gamla kringgåenden. “Frame-busting”-JavaScript (skript som försöker bryta sig ur ramar) är opålitligt och kan kringgås. Huvudena är den korrekta, webbläsarverkställda åtgärden.

Vanliga frågor