Wat is Referrer-Policy?

De HTTP-header Referrer-Policy bepaalt hoeveel informatie over de oorspronkelijke pagina wordt opgenomen in de Referer-request-header wanneer een gebruiker van uw site naar een andere navigeert, of wanneer uw pagina resources van externe bronnen laadt. Telkens als iemand op een link klikt, telkens als een afbeelding van een CDN wordt geladen, telkens als een analytics-script afgaat, stuurt de browser potentieel de URL van de huidige pagina naar de bestemmingsserver. Met Referrer-Policy bepaalt u hoeveel van die URL u deelt.

(Een korte opmerking over de spelling: de HTTP-header wordt geschreven als "Referer" met één "r" door een spelfout in de oorspronkelijke HTTP-specificatie uit het begin van de jaren negentig. De policy-header gebruikt de correcte spelling "Referrer" met twee r's. Beide spellingen zijn opzettelijk.)

Wat de Referer-header bevat en wanneer hij wordt verstuurd

Standaard (zonder Referrer-Policy) verstuurt de browser de volledige URL van de huidige pagina als Referer-header bij de meeste uitgaande requests. Dit omvat:

• Navigatie: wanneer een gebruiker op een link naar een andere website klikt, ontvangt de bestemming de volledige URL van de pagina waar hij vandaan kwam.
• Subresource-requests: wanneer uw pagina afbeeldingen, scripts, stylesheets of fonts van externe domeinen laadt, bevat elk request de Referer-header.
• Formulierinzendingen: wanneer een formulier gegevens naar een externe URL verstuurt, wordt de Referer-header meegestuurd.
• AJAX- en Fetch-requests: API-aanroepen naar externe diensten bevatten standaard ook de Referer-header.

Stel dat een bezoeker zich op deze URL van uw WordPress-site bevindt:

https://uwsite.com/leden/dashboard?session=abc123&plan=premium

Bevat die pagina een ingesloten afbeelding van een externe analyseprovider of advertentienetwerk, dan ontvangt de server van die provider de volledige URL in de Referer-header, inclusief de query-parameters met het sessietoken en plan-informatie. Dit is de privacyzorg die Referrer-Policy aanpakt.

Alle Referrer-Policy-waarden uitgelegd

De Referrer-Policy-header ondersteunt acht verschillende waarden. Elk definieert een ander niveau van informatie-uitwisseling:

• no-referrer: stuur de Referer-header helemaal nooit. De bestemming krijgt geen informatie over waar het request vandaan kwam. Dit is de meest privé-vriendelijke optie, maar kan functionaliteit breken die afhangt van referrer-data (sommige CSRF-beschermingen bijvoorbeeld).
• no-referrer-when-downgrade: stuur de volledige URL, maar laat de Referer weg bij navigatie van HTTPS naar HTTP (een "downgrade"). Dit was jarenlang de browserstandaard. Het beschermt tegen het lekken van URL's bij het verlaten van een veilige context, maar deelt alles bij HTTPS-naar-HTTPS-navigatie.
• origin: stuur alleen de origin (schema, host en poort), maar niet het pad of de query string. Dus https://uwsite.com/leden/dashboard?session=abc123 wordt slechts https://uwsite.com/. De bestemming weet vanaf welke site de bezoeker kwam, maar niet vanaf welke specifieke pagina.
• origin-when-cross-origin: stuur de volledige URL voor same-origin-requests (links binnen uw eigen site), maar alleen de origin voor cross-origin-requests. Dit geeft uw eigen analytics en interne tools volledige referrer-data, terwijl wordt beperkt wat externe sites zien.
• same-origin: stuur de volledige URL alleen voor same-origin-requests. Voor cross-origin-requests wordt helemaal geen Referer verstuurd. Dit is zeer privé voor externe navigatie, maar betekent dat externe diensten geen referrer-data ontvangen.
• strict-origin: stuur alleen de origin (zoals bij origin), maar laat de Referer volledig achterwege bij HTTPS-naar-HTTP-downgrades. Combineert de privacy van origin met de downgrade-bescherming van no-referrer-when-downgrade.
• strict-origin-when-cross-origin: de meest aanbevolen waarde. Hij stuurt de volledige URL voor same-origin-requests, alleen de origin voor cross-origin HTTPS-naar-HTTPS-requests, en niets bij HTTPS-naar-HTTP-downgrades. Dit is de beste balans tussen privacy, beveiliging en functionaliteit. Moderne browsers (Chrome 85+, Firefox 87+) hebben dit als standaard ingevoerd, ook wanneer er geen Referrer-Policy-header aanwezig is.
• unsafe-url: stuur altijd de volledige URL, ongeacht de bestemming of beveiligingscontext. Dit heet niet voor niets "unsafe". Het verstuurt query-parameters, paden en al het overige, ook naar HTTP-bestemmingen. Gebruik dit nooit, tenzij u een zeer specifieke behoefte heeft en de risico's begrijpt.

Privacy-implicaties van de Referer-header

De Referer-header is een belangrijke privacyzorg die veel site-eigenaren over het hoofd zien. Bedenk welke informatie uw URL's kunnen bevatten:

• Zoekopdrachten: heeft uw site een zoekfunctie, dan kan de URL er als /search?q=gevoelig+gezondheidsonderwerp uitzien. Elke externe resource die op de zoekresultatenpagina wordt geladen, ontvangt die query.
• Gebruikersidentificaties: URL's als /user/jan-jansen/profile of /order/12345 lekken gebruikers- en orderinformatie naar externe partijen.
• Tokens en sessiegegevens: sommige toepassingen plaatsen tokens in URL's voor wachtwoordresets, e-mailbevestigingen of deellinks. Deze kunnen via de Referer-header lekken.
• Interne URL-structuur: zelfs alleen de padstructuur (/wp-admin/, /alleen-leden/, /intern-dashboard/) onthult informatie over de architectuur van uw site.

Elke externe resource op uw pagina is een potentiële ontvanger van deze informatie: Google Fonts, analytics-scripts, social-media-knoppen, ingesloten video's, advertentienetwerken, op CDN's gehoste libraries en externe afbeeldingen. Elk daarvan ontvangt de Referer-header bij hun requests.

Relevantie voor GDPR en gegevensbescherming

Onder de GDPR en vergelijkbare privacywetgeving kunnen URL's met persoonlijke identificatoren of gevoelige informatie persoonsgegevens vormen. Bevatten uw URL's gebruikersnamen, e-mailadressen of andere identificeerbare informatie, dan kan het delen van die URL's via de Referer-header met derden een gegevensbeschermingsprobleem zijn.

Het instellen van een Referrer-Policy is een eenvoudige technische maatregel die onnodige gegevensuitwisseling met derden vermindert. Hoewel het niet expliciet vereist is door de GDPR, sluit het aan bij de principes van dataminimalisatie (artikel 5(1)(c)) en privacy by design (artikel 25). Vraagt uw functionaris voor gegevensbescherming of privacyaudit welke technische maatregelen u heeft getroffen om gegevenslekkage te beperken, dan is een correcte Referrer-Policy een concreet item om naar te verwijzen.

WordPress-standaardgedrag en gangbare plugins

WordPress core stelt standaard geen Referrer-Policy-header in. Dit betekent dat uw site afhankelijk is van de ingebouwde standaard van de browser. Voor moderne browsers is die standaard strict-origin-when-cross-origin, wat eigenlijk een redelijk beleid is. Toch zijn er enkele aandachtspunten:

• Oudere browsers vallen mogelijk nog terug op no-referrer-when-downgrade, dat de volledige URL verstuurt bij alle HTTPS-naar-HTTPS-requests.
• De header expliciet instellen is beter dan vertrouwen op browserstandaarden, omdat u zo uw intentie duidelijk communiceert en alle browserversies dekt.
• Sommige WordPress-beveiligingsplugins (zoals Sucuri of iThemes Security) bevatten een Referrer-Policy-optie in hun hardening-instellingen.
• WordPress 4.7.4 introduceerde verbeteringen aan de functie wp_get_referer(), maar dit is een server-side functie die de Referer-header leest voor CSRF-bescherming. Hij staat los van de Referrer-Policy-response-header.

Impact op website-analytics

Uw keuze voor Referrer-Policy beïnvloedt direct welke referrer-data uw analyse-tools ontvangen, en welke data andere sites ontvangen over verkeer vanaf uw site:

• Uw eigen analytics: gebruikt u Google Analytics, Matomo of een vergelijkbare tool met een trackingscript op uw site, dan bevatten same-origin-requests altijd de volledige referrer ongeacht het beleid (de meeste beleidsregels beperken alleen cross-origin-referrers). Uw on-site analytics-data wordt dus niet beïnvloed door de meeste beleidswaarden.
• Tracking van inkomend verkeer: de Referrer-Policy die u instelt beïnvloedt wat andere sites zien wanneer uw bezoekers vanuit uw site komen. Hij beïnvloedt niet wat u ziet over verkeer naar uw site (dat hangt af van het beleid van de verwijzende site).
• Affiliate- en partnertracking: heeft u een affiliate-programma of moet u uitgaande klikken volgen, dan zal een zeer restrictief beleid als no-referrer referrer-gebaseerde tracking breken. De aanbevolen waarde strict-origin-when-cross-origin stuurt de origin (het domein) naar partners, wat doorgaans voldoende is voor attributie.

Referrer-Policy instellen voor WordPress

De aanbevolen waarde voor de meeste WordPress-sites is strict-origin-when-cross-origin:

Referrer-Policy: strict-origin-when-cross-origin

Instellen in Apache:

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

In Nginx:

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

Via PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Verwerkt uw site bijzonder gevoelige gegevens (medische informatie, financiële gegevens, juridische documenten), dan kunt u een striktere policy overwegen, zoals same-origin of no-referrer. Wees u er alleen van bewust dat dit referrer-informatie verwijdert voor alle cross-origin-requests, wat externe diensten die daarvan afhankelijk zijn kan beïnvloeden.

Wat InspectWP controleert

InspectWP controleert of uw WordPress-site een Referrer-Policy-header verstuurt en rapporteert de geconfigureerde waarde. Ontbreekt de header, dan is uw site afhankelijk van de browserstandaard van elke bezoeker, die per browserversie verschilt. Een expliciet ingestelde Referrer-Policy zorgt voor consistent gedrag en toont aan dat u een bewuste beslissing heeft genomen over hoeveel URL-informatie uw site met derden deelt. Voor de overgrote meerderheid van WordPress-sites is strict-origin-when-cross-origin de aanbevolen waarde.