Defaults.Exposed › Åtgärder › Referrer-Policy

Hur du fixar Referrer-Policy

En Referrer-Policy är en engångsinstruktion din webbplats överlämnar till varje besökares webbläsare, som kontrollerar hur mycket av din webbadress som färdas med dem när de klickar på en länk till en annan webbplats. Utan den överlämnas hela adressen till den sida de befann sig på — söktermer, kontonummer, återställningslänkar, interna sidvägar och allt — tyst till nästa webbplats de landar på, inklusive annonsörer, analysföretag och var som helst en länk pekar.

Slutsats för ditt företag: Varje gång en besökare klickar på en utgående länk, annons eller delad resurs kan deras webbläsare överlämna hela adressen till din sida till destinationen — och om dina adresser innehåller sökfrågor, kundnummer, ordernummer eller engångslänkar läcker du kunddata till tredje parter du inte kontrollerar. Det är ett dataskyddsproblem som tillsynsmyndigheter tar på allvar, ett tyst brutet integritetsløfte, och ett betygsatt gap ett kunds säkerhetsteam flaggar under due diligence.

Vad detta kan kosta dig

• En kund fyller i ett formulär eller söker, klickar sedan på en utgående länk eller annons — och sidadressen, komplett med vad de skrivit, överlämnas direkt till en annonsör eller analysföretag du aldrig menade att dela det med.
• Lösenordsåterställnings- och kontoverifieringslänkar innehåller ibland en hemlig token i webbadressen; utan det här huvudet kan ett klick på vilken länk som helst på den sidan skicka hela adressen — token och allt — till en utomstående webbplats.
• Privata interna sidvägar (adminutrymmen, kundexklusiva sidor, prisnivåer, dokumentlänkar) avslöjas för varje tredje part dina besökare klickar igenom till, och ger konkurrenter och nyfikna en karta över din webbplats de aldrig borde se.
• En kunds säkerhetsgranskning eller integritetsrevision skannar din webbplats, ser ingen Referrer-Policy, och loggar det som ett datamitigeringsfel — den typen av fynd som stoppar ett kontrakt eller en certifiering.
• Persondata hamnar i händerna på behandlare du inte har något avtal med, vilket förvandlar ett femminuters förbiseende till ett rapporteringspliktigt dataskyddsbrott.

Varför det spelar roll. Webbläsare, som lämnas till sina egna enheter, är pratiga: som standard berättar de nästa webbplats var en besökare just kom från, ofta inklusive hela adressen till sidan. För en broschyrwebbplats kan det vara ofarligt, men i det ögonblick dina adresser innehåller något personligt — en sökterm, ett ordernummer, en e-post i en länk, en privat väg — läcker den standarden tyst ut det till utomstående parter. En Referrer-Policy är den enda inställningen som berättar för webbläsare att sluta överdela. Det är en betygsad kontroll på ditt betyg värd riktiga poäng, den kartläggs direkt till dataminimeringsplikter under integritetslagstiftning, och det är ett av de standardsäkerhetshuvuden varje professionell granskning förväntar sig att hitta.

Vad det här är, i klartext

Varje gång en besökare på din webbplats klickar på en länk till en annan webbplats — en utgående länk, en bannerannons, ett “dela detta”, till och med ett teckensnitt eller bild som laddas från någon annanstans — kopplar deras webbläsare tyst med en notering om vilken sida av din de kom från. Den noteringen kallas referrern.

Används förnuftigt är referrern ofarlig och till och med hjälpsam: det är hur andra webbplatser vet att trafik kom från dig, och det driver en hel del ärlig analys. Fångsten är i standardbeteendet. Utan hantering säger inte webbläsaren bara “de kom från ditt-företag.com” — den överlämnar ofta hela adressen till den exakta sidan, inklusive allt efter domännamnet. Och webbadresser bär mycket mer än folk inser: söktermer inmatade i din webbplats, order- och kontonummer, vägen till en privat sida enbart för medlemmar, till och med engångshemliga tokens i lösenordsåterställnings- och bekräftelselänkar.

En Referrer-Policy är en enda instruktion din webbplats skickar till webbläsaren om hur mycket av den noteringen det är tillåtet att dela. Du kan säga åt den att bara dela ditt domännamn, bara till andra sidor på din egna webbplats, eller ingenting alls. Tänk på det som skillnaden mellan att ge en okänd person din fullständiga hemadress med ditt dagliga schema bifogat, kontra att bara berätta för dem vilken stad du bor i.

Det här är en av en liten familj av “säkerhetshuvuden” — korta instruktioner din webbplats ger varje besökares webbläsare. Det ändrar inte hur din webbplats ser ut eller fungerar. Det förhindrar helt enkelt webbläsaren från att överdela för din räkning.

Vad det här kan kosta dig

Här är konkreta, vardagliga sätt en saknad eller tillåtande Referrer-Policy drabbar riktiga företag. Inget av dessa kräver en hackare — de händer automatiskt, varje dag, i normal användning.

• Den läckta sökningen. En kund söker på din webbplats efter något känsligt — en medicinsk produkt, en skuldrelaterad tjänst, en konkurrentjämförelse — och söktermen landar i sidadressen. De klickar sedan på en utgående länk eller en annons på den resultatsidan. Annonsören tar nu emot din adress med söktermen i den, och lär sig exakt vad din kund letade efter. Du gick aldrig med på att dela det, och du kan inte ta tillbaka det.

• Den exponerade återställningslänken. Många system lägger en hemlig engångstoken i adressen till lösenordsåterställnings-, e-postbekräftelse- eller “magiska inloggnings”-sidor. Om den sidan innehåller någon utgående länk eller tredjepartsresurs kan hela adressen — token och allt — överlämnas till en utomstående webbplats. I värsta fall ger det en tredje part nycklarna till ett konto.

• Webbplatskartan du gav bort gratis. Dina interna sidvägar avslöjar ofta din struktur: /admin, /enterprise-pricing, /clients/acme, /downloads/private-report. Utan det här huvudet tar varje utomstående webbplats dina besökare klickar igenom till emot dessa vägar. Konkurrenter lär sig dina prisnivåer och produktlinjer; skrapare lär sig vilka sidor som ska riktas mot.

• Den oönskade datadelningsrelationen. Integritetslagstiftning förväntar dig att veta vem dina kunders persondata går till och att ha ett avtal på plats. Att läcka sidadresser som innehåller kundnummer eller e-postadresser till annonsnätverk och analysföretag — utan avtal och utan samtycke — är exakt den typ av okontrollerat dataflöde som förvandlar en rutinrevision till ett fynd, och ett fynd till ett rapporteringspliktigt intrång.

• Affären som stannar under due diligence. När en större kunds säkerhetsteam granskar dig är saknade standardsäkerhetshuvuden ett snabbt, automatiserat bockhål. Att se Referrer-Policy frånvarande berättar för dem att grundläggande integritets-hygien aldrig konfigurerades — och det intrycket färgar allt annat i granskningen.

Vad det faktiskt är

Som standard följer webbläsare ett beteende som ungefär motsvarar “strict-origin-when-cross-origin” i moderna versioner — men du kan inte lita på det, för äldre webbläsare, inbäddade webvyer och vissa konfigurationer återgår fortfarande till att läcka mer. Det enda sättet att vara säker är att ange policyn uttryckligen. När du gör det väljer du en regel från en kort lista. De som spelar roll:

• no-referrer — dela ingenting. Nästa webbplats informeras om ingenting om var besökaren kom från. Maximal integritet; kan dämpa din remissanalys.
• same-origin — dela hela adressen bara när besökaren rör sig mellan sidor på din egna webbplats; dela ingenting med utomstående webbplatser.
• strict-origin-when-cross-origin — det rekommenderade standardalternativet. Inom din egna webbplats delas hela vägen; till utomstående webbplatser delas bara ditt nakna domännamn (och ingenting alls när man går från en säker sida till en osäker). Utomstående parter lär sig att trafiken kom från dig, men aldrig de privata detaljerna efter ditt domännamn.
• origin — dela alltid bara ditt domännamn, till och med inom din egna webbplats.

Och de två värdena att undvika, för betygskortet behandlar dem som inte bättre än att inte ha något huvud alls:

• unsafe-url — dela hela adressen med alla, alltid. Det här är sämsta fallet i ett enda ord.
• no-referrer-when-downgrade — det gamla webbläsarstandarden; det skickar fortfarande hela adressen till andra säkra webbplatser, och läcker allt som beskrivs ovan.

Vad “bra” ser ut som: ett Referrer-Policy-huvud är på plats och satt till ett restriktivt värde — för de flesta företag, strict-origin-when-cross-origin. Det håller remissanalys igång medan det säkerställer att ingenting förbi ditt domännamn någonsin når en utomstående webbplats.

Så här åtgärdar du det (gratis, ungefär 5 minuter)

Skicka det här avsnittet till din IT-person, webbutvecklare eller hostingsupport — åtgärden är gratis, det är en enda rad, och det bryter inte din webbplats. Det finns ingen riskfylld utrullning här: till skillnad från vissa säkerhetsinställningar kan en vettig Referrer-Policy inte stoppa dina länkar eller sidor från att fungera. Det trimar bara vad som delas med andra webbplatser.

Målet: sätt ett Referrer-Policy-svarshuvud med värdet strict-origin-when-cross-origin (eller ett striktare värde om du föredrar att dela ännu mindre).

Cloudflare (ingen kod — enklaste om du använder det): Instrumentpanelen → din domän → Regler → Omvandlingsregler → Ändra svarshuvud → Skapa regel → Sätt statisk → Huvud-namn Referrer-Policy, värde strict-origin-when-cross-origin → tillämpa på alla inkommande begäran → Driftsätt.

Google Workspace / Microsoft 365: dessa hanterar din e-post, inte din webbplats, så huvudet sätts var din webbplats faktiskt hostas (din webbvärd, CDN eller server) — inte i Workspace eller 365 admin. Identifiera värden och använd det matchande alternativet nedan.

Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache (i webbplatskonfigurationen eller .htaccess):

Header always set Referrer-Policy "strict-origin-when-cross-origin"

IIS (web.config):

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express:

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

WordPress / vanliga värdar: de flesta hanterade WordPress- och delade värdar låter dig lägga till svarshuvuden antingen via ett säkerhetsplugin, en “huvuden”-panel i hosting-kontrollpanelen, eller .htaccess-kodsnutten ovan. Om du är bakom Cloudflare är Cloudflare-metoden den renaste och tillämpas överallt på en gång.

Efter tillämpning: ladda din webbplats och kör om kontrollen, eller använd dina webbläsarens utvecklarverktyg (Nätverksflik → klicka på huvuddokumentet → Svarshuvuden) för att bekräfta att Referrer-Policy: strict-origin-when-cross-origin är på plats.

Vanliga misstag

• Sätta ett tillåtande värde och anta att det räknas. unsafe-url och no-referrer-when-downgrade läcker båda fortfarande hela adressen. Betygskortet ger dem noll — identisk med att inte ha något huvud. Om huvudet finns men poängen inte gör det, är det här nästan alltid varför.
• Sätta det bara på hemsidan. Huvudet bör skickas på varje sida, för läckor händer på sök-resultat, konto- och återställningssidor — inte hemsidan. Sätt det på server-, CDN- eller Cloudflare-nivå så att det tillämpas webbplatsövergripande automatiskt.
• Sätta det i HTML <meta>-taggar bara. En <meta name="referrer">-tagg fungerar för vissa fall men inte alla, och det är lätt att få det inkonsekvent över sidor. Att sätta det som ett ordentligt svarshuvud (metoderna ovan) är det pålitliga tillvägagångssättet.
• Låta ett lager åsidosätta ett annat. Om både din ursprungsserver och din CDN sätter huvudet med olika värden kan resultatet bli oförutsägbart. Välj ett ställe att hantera det — vanligtvis CDN:en eller Cloudflare om du har en — och håll resten konsistent.
• Behandla det som ett substitut för att hålla data borta från URL:er. Huvudet begränsar skadan, men den renare långsiktiga vanan är att inte lägga hemligheter och persondata i webbadresser från första början. Använd huvudet nu; ta upp URL-hygien med din utvecklare som en uppföljning.

En snabb notering om relaterade huvuden

Referrer-Policy sitter bredvid en liten uppsättning andra webbsäkerhetshuvuden vi kontrollerar — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options och ett fåtal avancerade cross-origin-huvuden. De skyddar olika saker, så att ha ett täcker inte de andra. Om din Referrer-Policy saknas är det värt att be den som åtgärdar den att bekräfta att de andra standardhuvudena är på plats samtidigt, eftersom de typiskt konfigureras på samma enda ställe och besöket kostar ingenting extra.

Kort sagt

Referrer-Policy är den billigaste, säkraste integritetsåtgärden på ditt betyg: en rad, ungefär fem minuter, ingen risk för att bryta något och gratis. Den förhindrar dina besökares webbläsare från att tyst överlämna dina privata sidadresser — och vilken persondata de innehåller — till varje utomstående webbplats de klickar igenom till. Sätt den till strict-origin-when-cross-origin, bekräfta att den är live på varje sida, och det medelhöga allvarlighetsgrads-gapet och dess 15 poäng är stängda.

Vanliga frågor