Deze pagina is vertaald door de Cloud Translation API.

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

Maud Nalpas

Voor we beginnen:

Als je niet zeker weet wat het verschil is tussen "site" en "origin", bekijk dan "same-site" en "same-origin" begrijpen .
In de Referer header ontbreekt 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 evolueren naar een privacyverhogend standaardbeleid voor verwijzingen, om een goede terugval te bieden wanneer een website geen beleid heeft ingesteld.
Chrome is van plan om in 1985 geleidelijk strict-origin-when-cross-origin als standaardbeleid in te stellen; dit kan van invloed zijn op gebruiksscenario's die vertrouwen op de verwijzende waarde van een andere oorsprong.
Dit is de nieuwe standaard, maar websites kunnen nog steeds een beleid naar keuze kiezen.
Om de wijziging in Chrome uit te proberen, schakelt u de vlag in chrome://flags/#reduced-referrer-granularity . Je kunt ook deze demo bekijken om de verandering in actie te zien.
Naast het verwijzingsbeleid kan de manier waarop browsers omgaan met verwijzingen veranderen, dus houd dit in de gaten.

Wat verandert er en waarom?

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

Welke informatie precies in de Referer header wordt verzonden in een verzoek van uw site, wordt bepaald door de Referrer-Policy header die u instelt.

Diagram: Verwijzer heeft een verzoek ingediend. — *Verwijzerbeleid en verwijzer.*

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

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 bepaalde fase van de overstap naar 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. 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 verzonden in de Referer header van cross-origin-verzoeken.

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-originele aanvraag. — *Verwijzer verzonden (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 : Verwijzer: https: //site-one.example/stuff/detail?tag=red .
Met strict-origin-when-cross-origin : verwijzing: https://site-one.example/.

Wat blijft hetzelfde?

Net als no-referrer-when-downgrade strict-origin-when-cross-origin veilig : er is geen referrer ( Referer header en document.referrer ) aanwezig wanneer het verzoek wordt gedaan van een HTTPS-oorsprong (beveiligd) naar een HTTP-oorsprong ( onzeker). Op deze manier zullen, als uw website HTTPS gebruikt ( zo niet, maak er dan een prioriteit van ), de URL's van uw website niet lekken in niet-HTTPS-verzoeken, omdat iedereen op het netwerk deze kan zien, dus dit zou uw gebruikers blootstellen aan manipulatie -de-midden-aanvallen.
Binnen dezelfde oorsprong is de waarde van de Referer header 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 : verwijzing: https: //site-one.example/stuff/detail?tag=red

Wat is de impact?

Op basis van discussies met andere browsers en Chrome's eigen experimenten in Chrome 84 wordt verwacht dat de voor de gebruiker zichtbare breuk beperkt zal zijn .

Logboeken of analyses aan de serverzijde die afhankelijk zijn van de beschikbaarheid van de volledige verwijzende URL, zullen waarschijnlijk worden beïnvloed door een verminderde granulariteit van die informatie.

Wat moet je doen?

Chrome is van plan het nieuwe standaard verwijzingsbeleid in 85 uit te rollen (juli 2020 voor bèta, augustus 2020 voor stabiel). Bekijk de status in het Chrome-statusitem .

Begrijp en detecteer de verandering

Om te begrijpen wat de nieuwe standaard in de praktijk verandert, kun je deze demo bekijken.

U kunt deze demo ook gebruiken om te detecteren welk beleid wordt toegepast op de Chrome-instantie die u gebruikt.

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

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

Chrome-screenshot: hoe u de vlag chrome://flags/#reduced-referrer-granularity inschakelt. — *De vlag inschakelen.*

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

Een ander ding dat u kunt doen om impact te detecteren, is controleren of de codebase van uw website de referrer gebruikt, hetzij via de Referer header van inkomende verzoeken op de server, hetzij vanuit document.referrer in JavaScript.

Bepaalde functies op uw site werken mogelijk niet goed of gedragen zich anders als u de verwijzende verwijzing van verzoeken van een andere oorsprong naar uw site gebruikt (meer specifiek het pad en/of de queryreeks) EN deze oorsprong het standaard verwijzende beleid van de browser gebruikt (dat wil zeggen dat er geen beleid ingesteld).

Als dit van invloed is op uw site, overweeg dan alternatieven

Als u de verwijzer gebruikt om toegang te krijgen tot het volledige pad of de queryreeks voor verzoeken aan uw site, heeft u een aantal opties:

Gebruik alternatieve technieken en headers zoals Origin en Sec-fetch-Site voor uw CSRF-beveiliging, logboekregistratie en andere gebruiksscenario's. Bekijk Verwijzer en Verwijzerbeleid: best practices .
U kunt met partners afstemmen op een specifiek beleid als dit nodig en transparant is voor uw gebruikers. Toegangscontrole (wanneer de verwijzer door websites wordt gebruikt om specifieke toegang tot hun bronnen tot andere bronnen te verlenen) zou zo'n geval kunnen zijn, hoewel met de wijziging van Chrome de oorsprong nog steeds wordt gedeeld in de Referer Header (en in document.referrer ).

Merk op dat de meeste browsers zich in een vergelijkbare richting bewegen als het gaat om de verwijzer (zie browserstandaarden en hun evoluties in Verwijzer en Verwijzerbeleid: best practices .

Implementeer een expliciet, privacyverhogend beleid op uw hele site

Welke Referer moet worden verzonden in verzoeken die afkomstig zijn van uw website, dwz welk beleid moet u instellen voor uw site?

Zelfs met de verandering van Chrome in gedachten is het een goed idee om nu al een expliciet, privacyverhogend beleid in te voeren, zoals strict-origin-when-cross-origin of strenger.

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

Controleer Verwijzer en Verwijzerbeleid: best practices voor details over het instellen van een beleid.

Over Chrome Enterprise

Het Chrome-bedrijfsbeleid ForceLegacyDefaultReferrerPolicy is beschikbaar voor IT-beheerders die het vorige standaard verwijzende beleid van no-referrer-when-downgrade willen afdwingen in bedrijfsomgevingen. Hierdoor krijgen bedrijven extra tijd om hun applicaties te testen en bij te werken.

Dit beleid wordt verwijderd in Chrome 88.

Stuur feedback

Heeft u feedback om te delen of iets te melden? Deel feedback over het voornemen van Chrome om , of tweet uw vragen op @maudnals .

Met veel dank voor bijdragen en feedback aan alle reviewers - vooral Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck en Kayce Basques.