Een nieuw standaard verwijzingsbeleid voor Chrome: strict-origin-when-cross-origin

Maud Nalpas

Voordat we beginnen:

  • Als je niet zeker weet wat het verschil is tussen 'site' en 'origin', lees dan het artikel 'Same-site en same-origin begrijpen' .
  • De Referer header mist een R vanwege een oorspronkelijke spelfout in de specificatie. De Referrer-Policy header en referrer in JavaScript en de DOM zijn correct gespeld.

Samenvatting

  • Browsers ontwikkelen zich in de richting van privacyvriendelijkere standaardverwijzingsbeleidsregels, om een ​​goed alternatief te bieden wanneer een website geen beleid heeft ingesteld.
  • Chrome is van plan om strict-origin-when-cross-origin geleidelijk als standaardbeleid in te schakelen in versie 85; dit kan gevolgen hebben voor gebruikssituaties die afhankelijk zijn van de referrer-waarde van een andere oorsprong.
  • Dit is de nieuwe standaard, maar websites kunnen nog steeds een beleid naar keuze selecteren.
  • Om de wijziging in Chrome uit te proberen, schakel je de vlag in via chrome://flags/#reduced-referrer-granularity . Je kunt ook deze demo bekijken om de wijziging in actie te zien.
  • Naast het verwijzingsbeleid kan de manier waarop browsers met verwijzingen omgaan veranderen, dus houd dat in de gaten.

Wat verandert er en waarom?

HTTP-verzoeken kunnen de optionele Referer header bevatten, die de oorsprong of de URL van de webpagina aangeeft waarvandaan het verzoek is gedaan. De Referer-Policy header definieert welke gegevens beschikbaar worden gesteld in de Referer header en, voor navigatie en iframes, in de document.referrer van de bestemming.

Welke informatie er precies in de Referer header wordt meegestuurd bij een verzoek vanaf uw site, wordt bepaald door de Referrer-Policy header die u instelt.

Diagram: Verwijzer heeft een verzoek ingediend.
Verwijzingsbeleid en verwijzer.

Als er geen beleid is ingesteld, wordt het standaardbeleid van de browser gebruikt. Websites volgen vaak het standaardbeleid van de browser.

Voor navigatie en iframes kunnen de gegevens in de Referer header ook via JavaScript worden benaderd met behulp van document.referrer .

Tot voor kort was het standaardbeleid van browsers no-referrer-when-downgrade . Maar veel browsers zijn nu bezig met de overstap naar privacyvriendelijkere standaardinstellingen .

Chrome is van plan om vanaf versie 85 zijn standaardbeleid te wijzigen van no-referrer-when-downgrade naar strict-origin-when-cross-origin .

Dit betekent dat als er geen beleid is ingesteld voor uw website, Chrome standaard strict-origin-when-cross-origin zal gebruiken. Houd er rekening mee dat u nog steeds een beleid naar keuze kunt instellen; deze wijziging heeft alleen effect op websites waarvoor geen beleid is ingesteld.

Wat betekent deze verandering?

strict-origin-when-cross-origin biedt meer privacy . Met dit beleid wordt alleen de oorsprong in de Referer header van cross-origin-verzoeken verzonden.

Dit voorkomt het lekken van privégegevens die mogelijk toegankelijk zijn via andere delen van de volledige URL, zoals het pad en de queryreeks.

Diagram: Verwijzer verzonden afhankelijk van het beleid, voor een cross-origin verzoek.
De referent (en document.referrer) wordt verzonden voor een cross-origin verzoek, afhankelijk van het beleid.

Bijvoorbeeld:

Cross-origin verzoek, verzonden van https://site-one.example/ stuff/detail?tag=red naar https://site-two.example/…:

  • Met no-referrer-when-downgrade : Referer: https://site-one.example/ stuff/detail?tag=red .
  • Met strict-origin-when-cross-origin : Referer: https://site-one.example/.

Wat blijft hetzelfde?

  • Net als no-referrer-when-downgrade is strict-origin-when-cross-origin veilig : er is geen referrer ( Referer header en document.referrer ) aanwezig wanneer het verzoek wordt gedaan van een HTTPS-origin (veilig) naar een HTTP-origin (onveilig). Op deze manier, als uw website HTTPS gebruikt ( zo niet, maak het dan een prioriteit ), zullen de URL's van uw website niet lekken bij niet-HTTPS-verzoeken, omdat iedereen op het netwerk deze kan zien, waardoor uw gebruikers kwetsbaar zouden worden voor man-in-the-middle-aanvallen.
  • Binnen dezelfde oorsprong is de waarde van de Referer header de volledige URL.

Bijvoorbeeld: Same-origin request, verzonden van https://site-one.example/ stuff/detail?tag=red naar https://site-one.example/…:

  • Met strict-origin-when-cross-origin : Referer: https://site-one.example/ stuff/detail?tag=red

Wat zijn de gevolgen?

Op basis van gesprekken met andere browsers en de eigen experimenten van Chrome in Chrome 84, wordt verwacht dat de voor de gebruiker zichtbare problemen beperkt zullen blijven .

Server-side logging of analyses die afhankelijk zijn van de volledige referrer-URL zullen waarschijnlijk hinder ondervinden van een verminderde granulariteit van die informatie.

Wat moet je doen?

Chrome is van plan om het nieuwe standaardbeleid voor referrers te gaan uitrollen in versie 85 (juli 2020 voor de bètaversie, augustus 2020 voor de stabiele versie). Zie de status in het Chrome-statusbericht .

Begrijp en detecteer de verandering.

Om te begrijpen wat de nieuwe standaardwijzigingen in de praktijk betekenen, kunt u deze demo bekijken.

Je kunt deze demo ook gebruiken om te detecteren welk beleid wordt toegepast in de Chrome-instantie die je gebruikt.

Test de wijziging en ontdek of dit gevolgen heeft voor uw website.

Je kunt de wijziging al uitproberen vanaf Chrome 81: ga naar chrome://flags/#reduced-referrer-granularity in Chrome en schakel de vlag in. Wanneer deze vlag is ingeschakeld, gebruiken alle websites zonder beleid de nieuwe strict-origin-when-cross-origin .

Chrome-screenshot: hoe de vlag in te schakelen: chrome://flags/#reduced-referrer-granularity.
De vlag inschakelen.

Je kunt nu controleren hoe je website en backend zich gedragen.

Een andere manier om de impact te detecteren, is door te controleren of de code van uw website de referrer gebruikt – via de Referer header van inkomende verzoeken op de server, of via document.referrer in JavaScript.

Bepaalde functies op uw site kunnen niet goed werken of zich anders gedragen als u de referrer van verzoeken van een andere oorsprong naar uw site gebruikt (meer specifiek het pad en/of de queryreeks) EN deze oorsprong het standaard referrerbeleid van de browser gebruikt (d.w.z. er is geen beleid ingesteld).

Als dit gevolgen heeft voor uw website, overweeg dan alternatieven.

Als je de referrer gebruikt om het volledige pad of de queryreeks voor verzoeken aan je site te achterhalen, heb je een aantal opties:

  • Gebruik alternatieve technieken en headers zoals Origin en Sec-fetch-Site voor uw CSRF-bescherming, logboekregistratie en andere toepassingen. Bekijk Referer en Referrer-Policy: best practices .
  • U kunt, indien nodig en transparant voor uw gebruikers, met partners een specifiek beleid afstemmen. Toegangscontrole – waarbij websites de referrer gebruiken om specifieke toegang tot hun bronnen te verlenen aan andere origins – kan hiervan een voorbeeld zijn, hoewel de origin na de wijziging in Chrome nog steeds wordt gedeeld in de Referer Header (en in document.referrer ).

Merk op dat de meeste browsers een vergelijkbare richting opgaan als het gaat om de referrer (zie browserstandaarden en hun evolutie in Referer en Referrer-Policy: best practices) .

Implementeer een expliciet privacybeleid op uw hele website.

Welke Referer moet worden meegestuurd in verzoeken afkomstig van uw website, oftewel welk beleid moet u voor uw site instellen?

Zelfs met de recente wijziging van Chrome in gedachten, is het verstandig om nu al een expliciet privacybeleid in te stellen, zoals strict-origin-when-cross-origin of een nog strengere variant.

Dit beschermt uw gebruikers en zorgt ervoor dat uw website zich voorspelbaarder gedraagt ​​in verschillende browsers. Het geeft u vooral controle, in plaats van dat uw site afhankelijk is van de standaardinstellingen van de browser.

Raadpleeg 'Verwijzer' en 'Verwijzersbeleid: beste praktijken' voor meer informatie over het opstellen van een beleid.

Over Chrome Enterprise

Het Chrome-bedrijfsbeleid ForceLegacyDefaultReferrerPolicy is beschikbaar voor IT-beheerders die het vorige standaardbeleid voor referrers ( no-referrer-when-downgrade willen afdwingen in bedrijfsomgevingen. Dit geeft bedrijven extra tijd om hun applicaties te testen en bij te werken.

Dit beleid wordt verwijderd in Chrome 88.

Feedback verzenden

Heb je feedback of wil je iets melden? Geef feedback over de plannen van Chrome voor de release , of tweet je vragen naar @maudnals .

Hartelijk dank aan alle recensenten voor hun bijdragen en feedback, in het bijzonder Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck en Kayce Basques.

Bronnen