Referrer-Policy

Adatszivárgás URL-en keresztül

Sok rendszer tesz érzékeny adatot az URL-be. Jelszó-visszaállító token, meghívó-link, e-mail-cím a query stringben, belső kereső-kifejezés. Ha a beállítás unsafe-url, ezek mind eljutnak minden beágyazott külső szerverhez. Egy hirdetési pixel vagy betűtípus-CDN elég hozzá.

Mérés és attribúció

A GA4 a Referer fejlécből olvassa ki a hivatkozó forrást. Ha no-referrer van beállítva a partneroldalon, a forgalom nálad Direct lesz. Fordítva is igaz: a te szigorú beállításod a partnereid riportjaiban tünteti el a forrásodat. Affiliate-programoknál ez konkrét pénz.

GDPR és átláthatóság

A teljes URL-ek kiküldése harmadik feleknek adattovábbítás. Ha ez zajlik, szerepelnie kell az adatvédelmi tájékoztatóban. A szigorúbb irányelv egyszerűbb megfelelőséget jelent, mert kevesebb adat hagyja el az oldalt.

SEO és AI

A rangsorolásra nincs közvetlen hatása, és az AI-crawlerek sem foglalkoznak vele. A biztonsági higiénia része, amit auditok és beszállítói kérdőívek rendszeresen kérnek.

• Minden HTTPS-oldal: a fejléc bármilyen tartalomtípusnál értelmezhető.
• Webshopok: kiemelten, mert a kosár- és pénztár-oldalak URL-jeiben gyakran van azonosító.
• Fiókos rendszerek: ahol token vagy meghívó-kód kerül az URL-be, ott kötelező olvasmány.
• Portálok, hírek: itt a szigorú beállítás elveszi a partnerek méréséhez szükséges adatot, ezért érdemes egyeztetni.

Kevésbé kritikus egy statikus bemutatkozó oldalon, ahol nincs query string és nincs bejelentkezés. Staging és fejlesztői környezet esetén a no-referrer a legbiztonságosabb, mert a belső URL-struktúra sem szivárog ki. A fejléc nem helyettesíti a Content-Security-Policy vagy a HSTS beállítását.

1. Nyisd meg a böngésző devtoolsát, Network fül, kattints a fő HTML-dokumentumra.
2. A Response Headers alatt keresd a Referrer-Policy sort.
3. Parancssorból gyorsabb: curl -sI https://pelda.hu | grep -i referrer.
4. Nézd meg a HTML <head> részét is: ott lehet <meta name="referrer">, ami felülírja vagy kiegészíti a fejlécet.
5. Ellenőrizd a gyakorlatban: kattints egy külső linkre, és a cél oldal kérésénél nézd meg a Referer értéket.
6. Fejléc-ellenőrző szolgáltatások (például securityheaders.com) egy lépésben kiírják az összes biztonsági fejlécet.

Jó jel:

• Referrer-Policy: strict-origin-when-cross-origin vagy strict-origin.
• Bejelentkezés utáni felületen same-origin vagy no-referrer.
• A fejléc minden oldalon egységesen jelen van, nem csak a főlapon.

Rossz jel:

• unsafe-url bárhol az oldalon.
• no-referrer-when-downgrade, ami HTTP-célnál is átadja a teljes URL-t.
• Két helyen két különböző érték, fejlécben és meta tagben.
• Token vagy e-mail-cím az URL-ben, mellé engedékeny irányelv.

WordPress

1. A legtisztább út a szerver: Apache alatt .htaccess, nginx alatt a site-konfiguráció.
2. Ha nincs szerver-hozzáférésed, egy fejléc-kezelő biztonsági bővítmény is megteszi.
3. Kódból: a send_headers hook-ban add hozzá a header() hívást a gyerek-sablon functions.php fájljában.
4. Ürítsd a cache-t, majd curl -I paranccsal ellenőrizd.

Shopify

A Shopify alapból strict-origin-when-cross-origin értéket küld, és a fejlécet nem tudod átírni. Ha szigorítanál, a sablon theme.liquid fájljába tegyél <meta name="referrer" content="same-origin"> sort. Vedd figyelembe, hogy ez az appok méréseit is érinti.

Unas

A fejléceket a rendszer kezeli, közvetlen szerkesztés nincs. Amit tehetsz: a saját HTML-beszúrási mezőben helyezz el meta referrer taget. Egyedi domain és külső proxy esetén ott is beállítható.

Shoprenter

Sablon szinten a <head> tartalmába illeszthetsz meta referrer taget. Szerveroldali fejléc-módosításhoz nyiss ügyfélszolgálati jegyet. Előtte nézd meg, mit küld most a rendszer, mert lehet, hogy már rendben van.

Egyedi fejlesztés

1. Állítsd be a fejlécet a reverse proxyn vagy a CDN szintjén, hogy minden válaszra érvényes legyen.
2. Alapértéknek válaszd a strict-origin-when-cross-origin értéket.
3. Bejelentkezés utáni és fizetési útvonalakon lépj same-origin értékre.
4. Egyedi linknél felülírhatod: <a href="..." rel="noreferrer">.
5. Tedd be a beállítást a regressziós tesztek közé, hogy egy deploy ne vegye vissza.

• unsafe-url beállítás a jobb mérés reményében: minden token és belső keresés kiszivárog a beágyazott külső szolgáltatókhoz.
• no-referrer globálisan: a partnerek és az affiliate-rendszerek nem látják a forgalmad forrását, a saját mérésed is torzul.
• Fejléc és meta tag ütközése: két különböző érték él egymás mellett, és nehéz kideríteni, melyik hat.
• Csak a főoldalon van beállítva: a riportokban ezt látjuk a leggyakrabban, mert egy plugin csak bizonyos sablonokra teszi rá.
• Érzékeny adat marad az URL-ben: a fejléc csak csökkenti a kockázatot, a token helye nem a query string.
• Beállítás után nincs ellenőrzés: a cache vagy a CDN felülírja a fejlécet, és senki nem veszi észre.
• A fejléc önmagában biztonsági megoldásnak számít: a magyar KKV-oldalak többségén ez az egyetlen beállított fejléc, X-Content-Type-Options és Permissions-Policy nélkül.

Ajánlott alapbeállítás a szerveren. Apache:

<IfModule mod_headers.c>
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx:

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

Ellenőrzés és sablon szintű megoldás, ha nincs szerver-hozzáférésed:

curl -sI https://pelda.hu | grep -i "referrer-policy"
# Referrer-Policy: strict-origin-when-cross-origin

<head>
  <meta name="referrer" content="strict-origin-when-cross-origin">
</head>

<!-- Egyetlen linknél szigorítás: -->
<a href="https://kulso-partner.hu" rel="noreferrer">Partner oldala</a>

A strict-origin-when-cross-origin azt jelenti, hogy saját domainen belül teljes URL megy át, kifelé csak a https://pelda.hu/ rész, HTTPS-ről HTTP-re pedig semmi.