Deze pagina is vertaald door de Cloud Translation API.

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

Maud Nalpas

Voordat we beginnen:

Als u niet zeker weet wat het verschil is tussen "site" en "origin", lees dan "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 steeds meer naar standaardverwijzingsbeleid dat de privacy verbetert. Dit is een goede vangnet wanneer er op een website geen beleid is ingesteld.
Chrome is van plan om strict-origin-when-cross-origin geleidelijk als standaardbeleid in te schakelen in versie 85. Dit kan van invloed zijn op use cases waarbij de verwijzende waarde van een andere oorsprong nodig is.
Dit is de nieuwe standaard, maar websites kunnen nog steeds hun eigen beleid kiezen.
Om de wijziging in Chrome uit te proberen, schakelt u de vlag in op chrome://flags/#reduced-referrer-granularity . U kunt ook deze demo bekijken om de wijziging in actie te zien.
Naast het verwijzingsbeleid kan de manier waarop browsers met verwijzingen omgaan, veranderen. Houd dit dus in de gaten.

Wat verandert er en waarom?

HTTP-verzoeken kunnen de optionele Referer header bevatten, die de bron 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 wordt verzonden in de Referer -header in een verzoek vanaf uw site, wordt bepaald door de Referrer-Policy header die u instelt.

Diagram: Referent heeft een verzoek ingediend. — *Referrer-beleid en referent.*

Als er geen beleid is ingesteld, wordt de standaardinstelling van de browser gebruikt. Websites hanteren vaak de standaardinstelling van de browser.

Voor navigatie en iframes zijn de gegevens in de Referer header ook toegankelijk via JavaScript met behulp van document.referrer .

Tot voor kort was no-referrer-when-downgrade een wijdverbreid standaardbeleid in browsers. Maar nu bevinden veel browsers zich in een fase waarin ze overstappen op meer privacyverhogende standaardinstellingen .

Chrome is van plan om vanaf versie 85 het 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 gebruikt. U kunt nog steeds een beleid naar keuze instellen; deze wijziging is alleen van toepassing 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 meegestuurd in de Referer header van cross-origin-aanvragen.

Hiermee wordt voorkomen dat er privégegevens lekken die mogelijk toegankelijk zijn via andere delen van de volledige URL, zoals het pad en de queryreeks.

Diagram: Referer verzonden afhankelijk van het beleid, voor een cross-origin verzoek. — *Verwezen referent (en document.referrer) 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-bron (beveiligd) naar een HTTP-bron (onveilig). Op deze manier, als uw website HTTPS gebruikt ( zo niet, geef het dan prioriteit ), zullen de URL's van uw website niet lekken in niet-HTTPS-verzoeken, omdat iedereen op het netwerk deze kan zien. Dit zou uw gebruikers blootstellen aan man-in-the-middle-aanvallen.
Binnen dezelfde oorsprong is de Referer -headerwaarde de volledige URL.

Bijvoorbeeld: Verzoek van dezelfde oorsprong, 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 is de impact?

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

Logboekregistratie of analyses aan de serverzijde die afhankelijk zijn van de beschikbaarheid van de volledige verwijzende URL, ondervinden waarschijnlijk hinder van de verminderde gedetailleerdheid van die informatie.

Wat moet je doen?

Chrome is van plan om het nieuwe standaardverwijzingsbeleid in versie 85 uit te rollen (juli 2020 voor bèta, augustus 2020 voor stabiel). Zie de status in het Chrome-statusitem .

Begrijp en detecteer de verandering

Om te zien wat de nieuwe standaard in de praktijk betekent, kunt u deze demo bekijken.

U kunt deze demo ook gebruiken om te detecteren welk beleid wordt toegepast op het Chrome-exemplaar dat u uitvoert.

Test de wijziging en bepaal of dit gevolgen heeft voor uw site

U 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 .

Schermafbeelding van Chrome: hoe schakel je de vlag chrome://flags/#reduced-referrer-granularity in. — *De vlag inschakelen.*

U kunt nu controleren hoe uw website en backend zich gedragen.

U kunt de impact ook vaststellen door te controleren of de codebase van uw website de referrer gebruikt. Dit kan via de Referer header van inkomende verzoeken op de server of via document.referrer in JavaScript.

Bepaalde functies op uw site kunnen defect raken of anders gaan functioneren als u de verwijzende URL van verzoeken van een andere oorsprong naar uw site gebruikt (specifieker het pad en/of de queryreeks) EN deze oorsprong het standaardverwijzingsbeleid van de browser gebruikt (er is dus geen beleid ingesteld).

Als dit gevolgen heeft voor uw site, overweeg dan alternatieven

Als u de referrer gebruikt om toegang te krijgen tot het volledige pad of de queryreeks voor verzoeken aan uw site, hebt u een paar opties:

Gebruik alternatieve technieken en headers zoals Origin en Sec-fetch-Site voor uw CSRF-beveiliging, logging en andere use cases. Bekijk Referer en Referrer-Policy: best practices .
U kunt met partners een specifiek beleid afstemmen als dit nodig is en transparant is voor uw gebruikers. Toegangscontrole – wanneer de referrer door websites wordt gebruikt om specifieke toegang tot hun bronnen te verlenen aan andere bronnen – kan zo'n geval zijn, hoewel de bron na de wijziging in Chrome nog steeds wordt gedeeld in de Referer Header (en in document.referrer ).

Houd er rekening mee dat de meeste browsers een vergelijkbare richting uitgaan als het gaat om de referrer (zie browserstandaardinstellingen en hun ontwikkelingen in Referer en Referrer-Policy: aanbevolen procedures) .

Implementeer een expliciet, privacyverbeterend beleid op uw site

Welke Referer moet worden meegestuurd in verzoeken die afkomstig zijn van uw website? Welk beleid moet u met andere woorden instellen voor uw site?

Zelfs met de wijziging van Chrome in gedachten, is het een goed idee om nu al een expliciet, privacyverbeterend beleid in te stellen, zoals strict-origin-when-cross-origin stricter.

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 uw browser.

Raadpleeg Referrer en Referrer-Policy: best practices voor meer informatie over het instellen van een beleid.

Over Chrome Enterprise

Het Chrome Enterprise-beleid ForceLegacyDefaultReferrerPolicy is beschikbaar voor IT-beheerders die het vorige standaardreferrerbeleid ( no-referrer-when-downgrade willen afdwingen in zakelijke omgevingen. Dit geeft bedrijven extra tijd om hun applicaties te testen en bij te werken.

Dit beleid wordt verwijderd in Chrome 88.

Feedback sturen

Heb je feedback of wil je iets melden? Deel je feedback over de intentie van Chrome om te lanceren of tweet je vragen naar @maudnals .

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