Defaults.Exposed › Rettelser › Referrer-Policy

Sådan retter du Referrer-Policy

En Referrer-Policy er en ét-linjes instruktion din hjemmeside giver enhver besøgendes browser, der kontrollerer, hvor meget af din webadresse der følger med dem, når de klikker på et link til en anden side. Uden den gives den fulde adresse på den side de var på — søgetermer, kontonumre, nulstillingslinks, interne stier og alt — stille til den næste side de lander på, inklusive annoncører, analysevirksomheder og overalt ellers et link peger.

Det korte svar for din virksomhed: Hver gang en besøgende klikker på et udgående link, annonce eller delt ressource, kan deres browser give den fulde adresse på din side til destinationen — og bærer dine adresser søgeforespørgsler, kunde-ID'er, ordrenumre eller engangs-links, lækker du kundedata til tredjeparts du ikke kontrollerer. Det er et databeskyttelsesproblem regulatorer tager seriøst, et privatlivsløfte stille brudt, og et scoret hul en klients sikkerhedsteam vil flage under due diligence.

Hvad dette kan koste dig

En kunde udfylder en formular eller kører en søgning, derefter klikker de på et udgående link eller annonce — og sideadressen, komplet med hvad de tastede, gives direkte til en annoncør eller analysevirksomhed, du aldrig mente at dele med.
Adgangskode-nulstillings- og kontobekræftelseslinks bærer sommetider et hemmeligt token i webadressen; uden dette header kan klik på ethvert link på den side give den fulde adresse — token inkluderet — til en udenfor-side.
Private interne sigestier (adminområder, kun-for-kunder-sider, prissætningstiers, dokumentlinks) afsløres for enhver tredjepart dine besøgende klikker igennem til, og giver konkurrenter og snoops et kort over din side de aldrig burde se.
En klients sikkerhedsgennemgang eller en privatlivsrevision scanner din side, ser ingen Referrer-Policy og logger det som en dataminimeringsfejl — den slags fund der staller en kontrakt eller en certificering.
Persondata ender i hænderne på databehandlere du ingen aftale har med, og forvandler en fem-minutters forglemmelse til et reportabelt databeskyttelsesproblem.

Hvorfor det betyder noget. Browsere, overladt til sig selv, er snakkesaglige: som standard fortæller de den næste hjemmeside, hvor en besøgende kom fra, og inkluderer ofte den fulde adresse på siden. For en brochure-side er det muligvis harmløst, men det øjeblik dine adresser indeholder noget personligt — en søgeterme, et ordre-ID, en e-mail i et link, en privat sti — lækker den standard det stille til udenfor-parter. En Referrer-Policy er den enkelt indstilling der siger til browsere om at holde op med at overdele. Det er et scoret tjek på dit scorecard, der er reelle point værd, det kortlægger direkte til dataminimeringspligter under privatlivslovgivning, og det er en af de standard sikkerhedsheaders enhver professionel gennemgang forventer at finde.

Hvad dette er på klart dansk

Hver gang en besøgende på din hjemmeside klikker på et link til en anden side — et udgående link, en bannerannonce, en “del dette”, selv en skrifttype eller et billede indlæst et andet sted fra — vedhæfter deres browser stille en note om, hvilken side af din de kom fra. Den note hedder referreren.

Brugt fornuftigt er referreren harmløs og endda nyttig. Fangsten er i standardadfærden. Overladt uadministreret giver browseren ikke blot “de kom fra dinvirksomhed.com” — den videregiver ofte den fulde adresse på den præcise side, inklusive alt efter domænenavnet. Og webadresser bærer langt mere end folk indser: søgetermer tastet på din side, ordre- og kontonumre, stien til en privat kun-for-medlemmer-side, selv engangs-hemmelige tokens i adgangskode-nulstillings- og bekræftelseslinks.

En Referrer-Policy er en enkelt instruktion din hjemmeside sender til browseren om, hvor meget af den note den har lov til at dele. Du kan sige til den at dele kun dit domænenavn, kun til andre sider på din egen side, eller slet ingenting.

Hvad dette kan koste dig

Den lækkede søgning. En kunde søger på din side efter noget sensitivt, og søgetermlen lander i sideadressen. De klikker derefter på et udgående link. Annoncøren modtager nu din adresse med søgetermlen i den.
Det eksponerede nulstillingslink. Mange systemer sætter et hemmeligt engangs-token i adressen på adgangskode-nulstillings-, e-mailbekræftelses- eller “magisk login”-sider. Indeholder den side et udgående link eller en tredjepartsressource, kan den fulde adresse — token inkluderet — gives til en udenfor-side.
Det sitekort du gav væk gratis. Dine interne sigestier afslører ofte din struktur: /admin, /enterprise-pricing, /kunder/acme, /downloads/privat-rapport. Uden dette header modtager enhver udenfor-side dine besøgende klikker igennem til, disse stier.
Det uønskede data-delings-forhold. Privatlivslov forventer, at du ved, hvem dine kunders persondata går til og har en aftale på plads. At lække sideadresser der indeholder kunde-ID’er eller e-mailadresser til annoncenetværk og analysevirksomheder — uden aftale og uden samtykke — er præcis den type ukontrolleret dataflow der forvandler en rutinerevision til et fund.
Aftalen der staller ved due diligence. Når et større kundes sikkerhedsteam gennemgår dig, er manglende standard sikkerhedsheaders en hurtig, automatisk afkrydsning.

Hvad det faktisk er

Standardadfærden tilnærmes “strict-origin-when-cross-origin” i moderne versioner — men du kan ikke stole på det, fordi ældre browsere og visse konfigurationer stadig falder tilbage til at lække mere. Den eneste måde at være sikker på, er at sætte politikken eksplicit. Når du gør det, vælger du én regel fra en kort liste:

no-referrer — del ingenting.
same-origin — del den fulde adresse kun, når besøgende bevæger sig mellem sider på din egen side; del ingenting med udenfor-sider.
strict-origin-when-cross-origin — den anbefalede standard. Inden for din egen side deles den fulde sti; til udenfor-sider deles kun dit bare domænenavn. Udenfor-parter lærer, at trafikken kom fra dig, men aldrig de private detaljer efter dit domæne.
origin — del altid kun dit domænenavn, selv inden for din egen side.

Og de to værdier du skal undgå, fordi scorecardet behandler dem som ikke bedre end ikke at have noget header:

unsafe-url — del den fulde adresse med alle, altid.
no-referrer-when-downgrade — den gamle browserstandard; den sender stadig den fulde adresse til andre sikre sider.

Hvad “godt” ser ud som: et Referrer-Policy-header er til stede og sat til en restriktiv værdi — for de fleste virksomheder strict-origin-when-cross-origin.

Sådan fikser du det (gratis, cirka 5 minutter)

Overrækk dette afsnit til din IT-person, webudvikler eller hostingsupport — fikset er gratis, det er én enkelt linje, og det bryder ikke din side.

Cloudflare (ingen kode — nemmeste hvis du bruger det): Dashboard → dit domæne → Rules → Transform Rules → Modify Response Header → Opret regel → Sæt statisk → Headernavn Referrer-Policy, værdi strict-origin-when-cross-origin → Deployér.

Nginx:

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

Apache (i site-konfigurationen 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(); });

Efter at have anvendt det: indlæs din side og kør tjekket igen, eller brug din browsers devtools til at bekræfte Referrer-Policy: strict-origin-when-cross-origin er til stede.

Almindelige fejl

At sætte en tilladelig værdi og antage, at det tæller. unsafe-url og no-referrer-when-downgrade lækker begge stadig den fulde adresse. Scorecardet scorer dem nul.
At sætte det kun på forsiden. Headeret bør sendes på enhver side, fordi lækkerne sker på søgeresultater-, konto- og nulstillingssider.
At sætte det kun i HTML <meta>-tags. Et <meta name="referrer">-tag virker for nogle tilfælde men ikke alle. At sætte det som et ordentligt svar-header er den pålidelige tilgang.
At lade ét lag overstyre et andet. Sætter begge din kilde-server og dit CDN headeret med forskellige værdier, kan resultatet være uforudsigeligt.
At behandle det som erstatning for at holde data ude af URL’er. Headeret begrænser skaden, men den renere langtidsvane er ikke at sætte hemmeligheder og persondata i webadresser overhovedet.

Kort sagt

Referrer-Policy er den billigste, sikreste privatlivsrettelse på dit scorecard: én linje, cirka fem minutter, ingen risiko for at bryde noget og gratis. Det stopper dine besøgendes browsere i stille at videregive dine private sideadresser — og uanset hvilke persondata de indeholder — til enhver udenfor-side de klikker igennem til. Sæt det til strict-origin-when-cross-origin, bekræft at det er aktivt på enhver side, og medium-alvorligheds-hullet og dets 15 point er lukket.

FAQ

Jeg er ikke teknisk — er dette noget jeg faktisk kan klare?

Ja, og det er en af de nemmeste rettelser på hele scorecardet. Det er en enkelt linje tilføjet af den der kører din hjemmeside eller hosting, og på tjenester som Cloudflare er det et par klik uden nogen kode overhovedet. Send dem afsnittet 'Sådan fikser du det' nedenfor. Det er gratis, det tager cirka fem minutter, og i modsætning til nogle sikkerhedsindstillinger bryder det ingenting på din side.

Hvad betyder 'referrer' her overhovedet?

Når nogen klikker på et link fra din side til en anden hjemmeside, sender deres browser en note med om, hvilken side de kom fra — den note hedder referreren. Den er nyttig til ægte analytics. Problemet er, at noten som standard ofte inkluderer din fulde sideadresse, ikke kun dit domænenavn. Indeholder den adresse noget privat, deles det med. En Referrer-Policy lader dig trimme noten ned til blot dit domænenavn, eller slå det fra, så intet sensitivt lækker.

Er dette virkelig værd at gøre, selv om min side ikke håndterer betalinger?

Næsten helt sikkert ja. Du behøver ikke en checkout for at have private oplysninger i dine webadresser — søgekasser, kontaktformularer, kontosider, dokumentlinks og adgangskode-nulstillingsemails sætter alle rutinemæssigt data i adresselinjen. Og selv uden nogen persondata overhovedet giver lækage af dine interne sigestier til alle udenfor-sider dine besøgende klikker til, konkurrenter og scrapere et gratis kort over din side. Fikset koster ingenting og fem minutter, så der er ringe grund til at springe det over.

Kan det at slå dette til bryde min side eller min analytics?

Nej. Dette er et af de sikre headers — det kontrollerer kun, hvor mange adressedetaljer der deles med andre sider, ikke om links virker. Den anbefalede indstilling sender stadig dit domænenavn til udenfor-sider, så legitim referral-analytics fortsætter med at virke; det stopper blot den fulde private adresse fra at følge med. Der er ingen kun-se-prøvetilstand nødvendig.

Er dette et privatlivslovsspørgsmål eller blot rart at have?

Det kan være et ægte compliance-spørgsmål. Databeskyttelsesregler kræver, at du indsamler og deler kun de minimale persondata der er nødvendige, og at du ved, hvem dine data går til. Bærer dine adresser personidentifikatorer, og du lækker dem til annoncører eller analysevirksomheder uden aftale, er det en dataminimeringsfejl revisorer og regulatorer genkender.

Påvirker dette vores karakter, eller er det bare råd?

Det påvirker din karakter. Referrer-Policy-tjekket er scoret og op til 15 point værd i kategorien Websikkerhed. Et manglende header er markeret medium alvorlighed. Bemærk én fælde: at sætte headeret til en tilladelig værdi som 'unsafe-url' eller 'no-referrer-when-downgrade' scorer nul — det samme som ikke at have noget header — fordi disse værdier stadig lækker den fulde adresse.