Defaults.Exposed › Oplossingen › Referrer-Policy

Hoe je Referrer-Policy oplost

Een Referrer-Policy is één regel instructie die uw website aan de browser van elke bezoeker meegeeft en die bepaalt hoeveel van uw webadres meereist wanneer ze op een link naar een andere site klikken. Zonder haar wordt het volledige adres van de pagina waarop ze waren — zoektermen, accountnummers, herstellinks, interne paginapaden en al — stilletjes doorgegeven aan de volgende site waarop ze belanden, inclusief adverteerders, analyticsbedrijven en overal waar een link naartoe wijst.

De kern voor je bedrijf: Telkens als een bezoeker op een uitgaande link, advertentie of gedeelde bron klikt, kan zijn browser het volledige adres van uw pagina aan de bestemming geven — en als uw adressen zoekopdrachten, klant-ID's, ordernummers of eenmalige links bevatten, lekt u klantgegevens naar derden die u niet beheerst. Dat is een gegevensbeschermingsprobleem dat toezichthouders serieus nemen, een stilletjes gebroken privacybelofte, en een gescoord gat dat het securityteam van een klant bij due diligence aanmerkt.

Wat dit je kan kosten

• Een klant vult een formulier in of zoekt iets, klikt dan op een uitgaande link of advertentie — en het paginaadres, compleet met wat hij typte, gaat rechtstreeks naar een adverteerder of analyticsbedrijf met wie u dat nooit wilde delen.
• Wachtwoordherstel- en accountbevestigingslinks dragen soms een geheim token in het webadres; zonder deze header kan klikken op een link op die pagina het hele adres — inclusief token — doorgeven aan een externe site.
• Privé interne paginapaden (beheeromgevingen, klantenpagina's, prijsniveaus, documentlinks) worden onthuld aan elke derde waar uw bezoekers naartoe doorklikken, en geven concurrenten en nieuwsgierigen een kaart van uw site die ze nooit zouden mogen zien.
• Een securityreview of privacyaudit van een klant scant uw site, ziet geen Referrer-Policy en noteert het als een dataminimalisatiefout — het soort bevinding dat een contract of certificering laat vastlopen.
• Persoonsgegevens belanden in handen van verwerkers met wie u geen overeenkomst heeft, waardoor een verzuim van vijf minuten verandert in een meldplichtig datalek.

Waarom het ertoe doet. Browsers zijn van nature spraakzaam: standaard vertellen ze de volgende website waar een bezoeker net vandaan kwam, vaak inclusief het volledige adres van de pagina. Voor een brochuresite kan dat onschadelijk zijn, maar zodra uw adressen iets persoonlijks bevatten — een zoekterm, een order-ID, een e-mailadres in een link, een privépad — lekt die standaard dat stilletjes naar buitenstaanders. Een Referrer-Policy is de ene instelling die browsers zegt te stoppen met overdelen. Het is een gescoorde check op uw scorekaart die echte punten waard is, ze raakt direct aan dataminimalisatieplichten onder privacywetgeving, en ze is een van de standaard securityheaders die elke professionele review verwacht aan te treffen.

Wat dit is, in gewone woorden

Telkens als een bezoeker op uw website op een link naar een andere site klikt — een uitgaande link, een banneradvertentie, een „deel dit”, zelfs een lettertype of afbeelding die elders vandaan wordt geladen — voegt zijn browser stilletjes een briefje toe met de pagina van u waar hij vandaan kwam. Dat briefje heet de referrer.

Verstandig gebruikt is de referrer onschadelijk en zelfs nuttig: zo weten andere sites dat verkeer van u kwam, en het voedt veel eerlijke analytics. De adder zit in het standaardgedrag. Onbeheerd zegt de browser niet alleen „ze kwamen van uw-bedrijf.nl” — hij geeft vaak het volledige adres van de exacte pagina door, inclusief alles na de domeinnaam. En webadressen dragen veel meer dan mensen beseffen: zoektermen die in uw site zijn getypt, order- en accountnummers, het pad naar een privé ledenpagina, zelfs eenmalige geheime tokens in wachtwoordherstel- en bevestigingslinks.

Een Referrer-Policy is één instructie die uw website naar de browser stuurt en die zegt hoeveel van dat briefje gedeeld mag worden. U kunt zeggen alleen uw domeinnaam te delen, alleen met andere pagina’s op uw eigen site, of helemaal niets. Zie het als het verschil tussen een vreemde uw volledige huisadres met dagindeling toesteken, versus enkel vertellen in welke stad u woont.

Dit is een van een kleine familie „securityheaders” — korte instructies die uw site aan de browser van elke bezoeker geeft. Het verandert niets aan hoe uw site eruitziet of werkt. Het belet de browser enkel namens u over te delen.

Wat dit u kan kosten

Hier concrete, alledaagse manieren waarop een ontbrekende of toegeeflijke Referrer-Policy echte bedrijven bijt. Geen daarvan vereist een hacker — ze gebeuren automatisch, elke dag, bij normaal gebruik.

• De gelekte zoekopdracht. Een klant zoekt op uw site naar iets gevoeligs — een medisch product, een schulddienst, een concurrentievergelijking — en de zoekterm belandt in het paginaadres. Vervolgens klikt hij op een uitgaande link of advertentie op die resultatenpagina. De adverteerder ontvangt nu uw adres met de zoekterm erin, en leert precies waar uw klant naar zocht. U stemde daar nooit mee in, en u kunt het niet terugnemen.

• De blootgestelde herstellink. Veel systemen zetten een geheim eenmalig token in het adres van wachtwoordherstel-, e-mailbevestigings- of „magische login”-pagina’s. Bevat die pagina een uitgaande link of bron van derden, dan kan het volledige adres — token inbegrepen — aan een externe site worden gegeven. In het ergste geval geeft dat een derde de sleutels tot een account.

• De sitekaart die u gratis weggaf. Uw interne paginapaden onthullen vaak uw structuur: /admin, /enterprise-prijzen, /klanten/acme, /downloads/privé-rapport. Zonder deze header ontvangt elke externe site waar uw bezoekers naartoe klikken die paden. Concurrenten leren uw prijsniveaus en productlijnen; scrapers leren welke pagina’s te targeten.

• De ongewenste gegevensdeelrelatie. Privacywetgeving verwacht dat u weet waar de persoonsgegevens van uw klanten naartoe gaan en dat u een overeenkomst heeft. Paginaadressen met klant-ID’s of e-mailadressen lekken naar advertentienetwerken en analyticsbedrijven — zonder overeenkomst en zonder toestemming — is precies het soort ongecontroleerde gegevensstroom dat een routineaudit in een bevinding verandert, en een bevinding in een meldplichtig lek.

• De deal die vastloopt op due diligence. Wanneer het securityteam van een grotere klant u doorlicht, is het ontbreken van standaard securityheaders een snelle, geautomatiseerde aanvinklijst. De Referrer-Policy afwezig zien vertelt ze dat basale privacyhygiëne nooit is opgezet — en die indruk kleurt al het andere in de review.

Wat het feitelijk is

Standaard volgen browsers gedrag dat op moderne versies ruwweg gelijk is aan „strict-origin-when-cross-origin” — maar daar kunt u niet op vertrouwen, want oudere browsers, ingebedde webviews en bepaalde configuraties vallen nog terug op meer lekken. De enige manier om zeker te zijn, is de policy expliciet in te stellen. Doet u dat, dan kiest u één regel uit een korte lijst. De regels die ertoe doen:

• no-referrer — niets delen. De volgende site krijgt niets te horen over waar de bezoeker vandaan kwam. Maximale privacy; kan uw referral-analytics dempen.
• same-origin — het volledige adres alleen delen wanneer de bezoeker tussen pagina’s op uw eigen site beweegt; niets delen met externe sites.
• strict-origin-when-cross-origin — de aanbevolen standaard. Binnen uw eigen site wordt het volledige pad gedeeld; naar externe sites alleen uw kale domeinnaam (en helemaal niets bij de overgang van een beveiligde naar een onbeveiligde pagina). Buitenstaanders leren dat het verkeer van u kwam, maar nooit de privédetails na uw domein.
• origin — altijd alleen uw domeinnaam delen, ook binnen uw eigen site.

En de twee waarden om te vermijden, omdat de scorekaart ze niet beter behandelt dan helemaal geen header:

• unsafe-url — het volledige adres met iedereen delen, altijd. Het slechtste geval in één woord.
• no-referrer-when-downgrade — de oude browserstandaard; stuurt nog steeds het volledige adres naar andere beveiligde sites, en lekt alles wat hierboven is beschreven.

Hoe „goed” eruitziet: een Referrer-Policy-header is aanwezig en op een restrictieve waarde gezet — voor de meeste bedrijven strict-origin-when-cross-origin. Dit houdt referral-analytics werkend en zorgt tegelijk dat niets voorbij uw domeinnaam ooit een externe site bereikt.

Hoe los je het op (gratis, ongeveer 5 minuten)

Geef dit onderdeel aan uw IT’er, webontwikkelaar of hostingsupport — de oplossing is gratis, het is één regel, en het breekt uw site niet. Er is hier geen riskante uitrol: anders dan sommige beveiligingsinstellingen kan een verstandige Referrer-Policy uw links of pagina’s niet laten stoppen met werken. Ze knipt alleen wat met andere sites wordt gedeeld.

Het doel: stel een Referrer-Policy-response-header in met de waarde strict-origin-when-cross-origin (of een strengere waarde als u nog minder wilt delen).

Cloudflare (geen code — makkelijkst als u het gebruikt): Dashboard → uw domein → Rules → Transform Rules → Modify Response Header → Create rule → Set static → Header name Referrer-Policy, value strict-origin-when-cross-origin → toepassen op alle binnenkomende verzoeken → Deploy.

Google Workspace / Microsoft 365: deze beheren uw e-mail, niet uw website, dus de header wordt ingesteld waar uw site werkelijk wordt gehost (uw webhost, CDN of server) — niet in de Workspace- of 365-beheeromgeving. Identificeer de host en gebruik de bijpassende optie hieronder.

Nginx:

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

Apache (in de siteconfig of .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 / gangbare hosts: de meeste managed WordPress- en shared hosts laten u response-headers toevoegen via een securityplugin, een „headers”-paneel in het hostingconfiguratiescherm, of het .htaccess-fragment hierboven. Zit u achter Cloudflare, dan is de Cloudflare-methode het schoonst en wordt ze overal tegelijk toegepast.

Na het toepassen: laad uw site en draai de check opnieuw, of gebruik de devtools van uw browser (tabblad Network → klik op het hoofddocument → Response Headers) om te bevestigen dat Referrer-Policy: strict-origin-when-cross-origin aanwezig is.

Veelgemaakte fouten

• Een toegeeflijke waarde instellen en aannemen dat die telt. unsafe-url en no-referrer-when-downgrade lekken beide nog het volledige adres. De scorekaart scoort ze nul — identiek aan geen header. Is de header aanwezig maar de punten niet, dan is dit vrijwel altijd waarom.
• Hem alleen op de homepage zetten. De header hoort op elke pagina te worden gestuurd, want de lekken gebeuren op zoekresultaat-, account- en herstelpagina’s — niet de homepage. Stel hem in op server-, CDN- of Cloudflare-niveau zodat hij automatisch sitebreed geldt.
• Hem alleen in HTML <meta>-tags zetten. Een <meta name="referrer">-tag werkt in sommige gevallen maar niet alle, en is makkelijk inconsistent te maken over pagina’s. Hem als echte response-header instellen (de methoden hierboven) is de betrouwbare aanpak.
• De ene laag de andere laten overschrijven. Stellen zowel uw origin-server als uw CDN de header met verschillende waarden in, dan kan het resultaat onvoorspelbaar zijn. Kies één plek om hem te beheren — meestal het CDN of Cloudflare als u dat heeft — en houd de rest consistent.
• Hem behandelen als vervanging voor data uit URL’s houden. De header beperkt de schade, maar de schonere gewoonte voor de lange termijn is om geheimen en persoonsgegevens om te beginnen niet in webadressen te zetten. Gebruik de header nu; kaart de URL-hygiëne als vervolg aan bij uw ontwikkelaar.

Een korte noot over de verwante headers

Referrer-Policy staat naast een kleine set andere websecurityheaders die we controleren — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, en enkele geavanceerde cross-origin-headers. Ze beschermen verschillende dingen, dus de ene dekt de andere niet. Ontbreekt uw Referrer-Policy, dan is het de moeite waard om wie het oplost te vragen meteen te bevestigen dat de andere standaardheaders op hun plek staan, want ze worden doorgaans op diezelfde ene plek geconfigureerd en het kost niets extra.

Kort gezegd

Referrer-Policy is de goedkoopste, veiligste privacyoplossing op uw scorekaart: één regel, zo’n vijf minuten, geen risico om iets te breken, en gratis. Ze belet de browsers van uw bezoekers stilletjes uw privé-paginaadressen — en alle persoonsgegevens die ze bevatten — door te geven aan elke externe site waar ze naartoe klikken. Stel haar op strict-origin-when-cross-origin, bevestig dat ze op elke pagina live is, en het middelhoge-ernstgat en zijn 15 punten zijn gedicht.

Veelgestelde vragen