Biztonsági HTTP-fejlécek beállítása WordPress-oldalon

Scheo · 2026-10-12 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A WordPress-oldalak biztonságáról többnyire a frissítések, a jelszavak és a mentések jutnak eszünkbe. A biztonsági HTTP-fejlécek ehhez képest csendes réteget adnak. Nem a szervert védik, a látogató böngészőjének mondják meg, mit engedhet meg az oldaladnak és mit nem. Ebben a cikkben végigmegyünk az öt leggyakoribb fejlécen, megmutatjuk, hogyan nézheted meg a mostani állapotot, hol érdemes beállítani őket, és milyen sorrendben vezesd be őket úgy, hogy közben ne törjön el a mérés vagy a beágyazott tartalom.

A szövegben három jelölést használunk. A Hivatalosan igazolt állítás szabványon vagy gyártói dokumentáción alapul, a Saját tapasztalat a napi WordPress-üzemeltetési munkánkból jön, a Szakmai feltételezés pedig megalapozott, de nem bizonyított következtetés.

Mit csinálnak a biztonsági HTTP-fejlécek, és miért érdemes foglalkozni velük WordPress alatt?

A biztonsági HTTP-fejlécek a szerver válaszával együtt érkező utasítások, amelyek a böngésző viselkedését szigorítják. Megszabhatják például, hogy az oldal csak titkosított kapcsolaton töltődjön be, honnan futhat rajta szkript, és beágyazhatja-e más webhely keretbe.

Hivatalosan igazolt: ezek a fejlécek a böngészőben érvényesülnek, tehát a feltört bővítményt vagy a gyenge admin jelszót nem pótolják. Azt a kárt csökkentik, amit egy már bejutott kártékony kód vagy egy megtévesztő külső oldal a látogatónál okozni tud.

WordPress alatt azért van ennek külön súlya, mert egy átlagos oldal sok külső forrásból tölt be kódot. A sablon, az oldalépítő, a mérőkódok, a betűkészletek, a chat és a térkép mind más-más domainről érkezik. Minél több a külső forrás, annál nagyobb a támadási felület, és annál több munka egy szigorú szabályrendszer összeállítása.

Melyik fejléc mit véd?

Az öt leggyakoribb fejléc öt különböző kockázatot kezel, ezért nem helyettesítik egymást. Az alábbi áttekintés mindegyiknél megadja a jellemző értéket is.

Strict-Transport-Security (HSTS)

A HSTS arra utasítja a böngészőt, hogy a megadott ideig kizárólag HTTPS-en keresztül kapcsolódjon a domainhez. Ezzel kivédi azt a helyzetet, amikor valaki egy nyilvános wifin a titkosítatlan első kérést téríti el. Jellemző érték: max-age=31536000; includeSubDomains, ahol a szám egy évnek megfelelő másodperc. Hivatalosan igazolt: a böngésző csak HTTPS-válaszban érkező HSTS-fejlécet vesz figyelembe, a sima HTTP-n küldöttet eldobja.

Content-Security-Policy (CSP)

A CSP egy engedélyezőlista arról, hogy az oldal honnan tölthet be szkriptet, stíluslapot, képet, keretet, és hová küldhet adatot. Ez a leghatékonyabb védelem a befecskendezett szkriptek (XSS) ellen, és egyben a legnehezebben beállítható fejléc. A legfontosabb direktívák a default-src, a script-src, a style-src, az img-src, a connect-src, a frame-src és a frame-ancestors.

X-Frame-Options

Ez a fejléc megtiltja, hogy az oldaladat más webhely keretbe ágyazza, így véd a kattintáseltérítés (clickjacking) ellen. A két használható érték a DENY és a SAMEORIGIN. Hivatalosan igazolt: a korszerű megfelelője a CSP frame-ancestors direktívája, az ALLOW-FROM értéket pedig a mai böngészők már nem támogatják. A két megoldás egyszerre is küldhető.

Referrer-Policy

Azt szabályozza, mennyi információt ad át a böngésző a hivatkozó oldalról, amikor a látogató továbbkattint. A strict-origin-when-cross-origin érték külső oldal felé csak a domaint küldi el, a teljes URL-t nem, így a címben szereplő keresőkifejezés vagy azonosító nem szivárog ki. A mai böngészők alapértelmezése is ez, a kifejezett beállítás mégis hasznos, mert egységessé teszi a viselkedést.

Permissions-Policy

Itt azt adod meg, mely böngészőfunkciókat használhatja az oldal és a benne lévő beágyazott tartalom. Ilyen a kamera, a mikrofon és a helymeghatározás. Egy tipikus céges oldalon elég ennyi: camera=(), microphone=(), geolocation=(). Ha az oldalon van „közelben lévő üzlet” kereső, a helymeghatározást a saját domainre engedd (geolocation=(self)). Hivatalosan igazolt: a fejléc böngészőtámogatása nem egységes, a Chromium-alapú böngészők kezelik a legteljesebben.

Az öt mellé érdemes felvenni az X-Content-Type-Options: nosniff fejlécet is. Ez megakadályozza, hogy a böngésző kitalálja egy fájl típusát, és például egy feltöltött képet szkriptként futtasson.

Hogyan ellenőrizheted, milyen fejléceket küld most az oldalad?

A meglévő állapotot három módon nézheted meg, a böngésző fejlesztői eszközeivel, parancssorból vagy egy online elemzővel. Mindhárom ugyanazt a szerverválaszt mutatja, csak más kényelmi szinten.

1. Böngésző: nyisd meg a fejlesztői eszközöket (F12), válaszd a Network fület, töltsd újra az oldalt, kattints a legelső, dokumentum típusú kérésre, és nézd meg a Response Headers részt.
2. Parancssor: a curl -I https://pelda.hu parancs csak a fejléceket kéri le. Futtasd le a főoldalra, egy aloldalra és egy képfájlra is.
3. Online elemző: a Security Headers és az MDN HTTP Observatory betűjeles értékelést ad, és felsorolja a hiányzó fejléceket.

Saját tapasztalat: a leggyakoribb meglepetés az, hogy a főoldal megkapja a fejléceket, a gyorsítótárból kiszolgált aloldalak vagy a 404-es oldal viszont nem. Ezért ne elégedj meg egyetlen URL ellenőrzésével. Az online elemzők osztályzatát kezeld tájékozódási pontként. Egy jól működő, szűkebb szabályrendszer többet ér, mint egy A+ értékelés, amely mellett nem megy a mérés.

Hol állíthatod be a fejléceket: tárhely, .htaccess, Cloudflare vagy bővítmény?

A fejléceket ott érdemes kiküldeni, ahol minden válaszra rákerülnek, vagyis a webszerver vagy a CDN szintjén. A bővítmény kényelmes, de a lefedettsége a leggyengébb.

Tárhely és .htaccess

Apache és LiteSpeed szerveren a .htaccess fájlba írhatsz, ha a mod_headers modul be van kapcsolva. Két példasor:

Header always set X-Frame-Options "SAMEORIGIN"

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

Az always kulcsszó azért kell, hogy a hibaoldalak is megkapják a fejlécet. Nginx alatt nincs .htaccess, ott a szerverkonfigurációba kerül az add_header utasítás, szintén always paraméterrel. Hivatalosan igazolt: Nginx alatt egy beágyazott blokkban megadott add_header felülírja a szülő blokkból örökölt fejléceket, emiatt a statikus fájlokra külön is vissza kell írni őket. Osztott tárhelyen a kezelőfelület gyakran kínál HSTS-kapcsolót. Ha Nginx fut és nincs hozzáférésed a konfigurációhoz, a tárhelyszolgáltató ügyfélszolgálata tudja beállítani.

Cloudflare

A Cloudflare a HSTS-t külön kapcsolóval kezeli az SSL/TLS beállítások között, a többi fejlécet pedig a válaszfejlécet módosító szabályokkal (Transform Rules) adhatod hozzá. Az előnye, hogy a peremhálózaton minden válaszra rákerül, a gyorsítótárazottra is. Arra figyelj, hogy ugyanazt a fejlécet ne küldje a szerver és a Cloudflare is eltérő értékkel. Két különböző CSP esetén a böngésző mindkettőt érvényesíti, vagyis a szigorúbb metszet lép életbe.

Bővítmény

A fejléckezelő bővítmények PHP-ból, a WordPress send_headers horgán keresztül dolgoznak. Saját tapasztalat: ebből két korlát következik. A statikus fájlokra (kép, CSS, JS) a fejléc nem kerül rá, és ha egy oldalgyorsító a kész HTML-t a PHP megkerülésével szolgálja ki, a gyorsítótárazott oldalakról is lemaradhat. Bővítményt akkor válassz, ha a szerverhez nincs hozzáférésed, és utána a fenti három módszerrel ellenőrizd az eredményt.

Milyen mellékhatást okozhat egy túl szigorú CSP a mérőkódokra, a chatre vagy a beágyazott térképre?

A túl szigorú CSP látható hibaüzenet nélkül blokkolja azt a külső forrást, amely nincs az engedélyezőlistán. Az oldal szépen betöltődik, közben a mérés leáll, a chat ablak nem jelenik meg, a térkép helyén pedig üres doboz marad.

• Mérőkódok: a Google Tag Manager és a GA4 a script-src mellett a connect-src és az img-src direktívában is engedélyt igényel, mert az adatküldés külön domainre megy. A Tag Managerben lévő egyedi HTML-címkék soron belüli szkriptként futnak, ezeket a CSP nonce vagy 'unsafe-inline' nélkül letiltja. A Meta Pixel szintén külön szkript- és képforrást használ.
• Chat: a chat widgetek jellemzően szkriptet, stíluslapot, keretet és folyamatos (WebSocket) kapcsolatot is nyitnak. Ha a connect-src listáról hiányzik a wss:// kezdetű cím, a buborék megjelenik, az üzenet viszont nem megy el.
• Térkép és videó: a beágyazott Google Térkép és a YouTube-videó a frame-src direktívában kér helyet. A reCAPTCHA-val védett űrlap szkript- és keretforrást is igényel.
• Betűkészletek: a külső betűkészlet a style-src és a font-src listában is szerepeljen, különben az oldal tartalék betűtípusra vált.
• WordPress-admin és oldalépítők: a szerkesztőfelület sok soron belüli szkriptet és stílust használ. Saját tapasztalat: a szigorú szabályt érdemes csak a nyilvános oldalakra alkalmazni, az admin felületet pedig külön kezelni.

Hivatalosan igazolt: a pontos domainlistát a Google a Tag Platform dokumentációjában közli, és időnként módosítja. A blokkolt forrásokat a böngésző konzolja (Console fül) soronként kiírja, onnan olvasható ki, mit kell még engedélyezni. A csendes mérésleállás azért veszélyes, mert a hirdetési rendszerek konverzió nélkül maradnak, és a hibát sokszor csak hetekkel később, a riportból veszi észre valaki.

Milyen sorrendben érdemes bevezetni a fejléceket report-only módból indulva?

A biztonságos sorrend az alacsony kockázatú fejlécekkel kezd, a HSTS-t lépcsőzetesen szigorítja, a CSP-t pedig megfigyelő üzemmódban indítja. Így minden lépés után van idő ellenőrizni, és egy hiba gyorsan visszavonható.

1. Kiinduló állapot rögzítése. Mentsd el a mostani fejléceket, és írd össze, milyen külső szolgáltatások futnak az oldalon (mérés, chat, térkép, videó, űrlapvédelem, betűkészlet, fizetési kapu).
2. Alacsony kockázatú fejlécek. Kapcsold be az X-Content-Type-Options, a Referrer-Policy, az X-Frame-Options: SAMEORIGIN és a Permissions-Policy fejlécet. Ha az oldaladat szándékosan ágyazza be egy partner, előbb egyeztess vele.
3. HSTS rövid idővel. Indíts max-age=300 értékkel, vagyis öt perccel. Ha minden rendben, emeld egy hétre, majd egy évre.
4. includeSubDomains. Csak akkor add hozzá, ha minden aldomain (levelező webfelület, régi teszt, belső rendszer) érvényes tanúsítvánnyal fut.
5. CSP report-only módban. Küldd ki a Content-Security-Policy-Report-Only fejlécet a tervezett szabállyal és jelentési végponttal (report-uri, illetve report-to). Ilyenkor a böngésző semmit nem blokkol, csak jelenti, mit blokkolna.
6. Adatgyűjtés és finomítás. Gyűjts jelentéseket legalább egy-két hétig, hogy a ritkábban látogatott oldalak és a kampányidőszak is belekerüljön. Egészítsd ki a listát a jogos forrásokkal, a böngészőbővítmények okozta zajt pedig szűrd ki.
7. Élesítés. Cseréld a fejléc nevét Content-Security-Policy-ra. A report-only változat párhuzamosan is futhat egy szigorúbb szabállyal, így a következő szigorítás is kockázat nélkül tesztelhető.
8. HSTS preload. Ez legyen a legutolsó lépés. Hivatalosan igazolt: a preload listára kerüléshez legalább egyéves max-age, includeSubDomains és preload kell, a listáról való lekerülés pedig hónapokig tarthat.

Hivatalosan igazolt: a report-only üzemmód csak valódi HTTP-fejlécként működik, HTML meta elemben nem, és a frame-ancestors direktívát a böngésző szintén figyelmen kívül hagyja a meta elemben. Kiinduló szabálynak sok WordPress-oldalon a default-src 'self' és a szükséges külső domainek listája szolgál. A soron belüli szkriptekhez első körben a legtöbben megengedik az 'unsafe-inline' értéket, ami gyengíti a védelmet, a nonce-alapú megoldás viszont WordPress alatt fejlesztői munkát kíván.

Számít-e mindez a keresőknek és az AI-válaszmotoroknak?

A biztonsági fejlécek közvetlen rangsorolási hatására nincs hivatalos megerősítés. Hivatalosan igazolt: a Google a HTTPS-t régóta enyhe rangsorolási jelként kezeli, a feltört, kártékony kódot terjesztő oldalakat pedig figyelmeztetéssel jelölheti meg a találati listán.

Szakmai feltételezés: a fejlécek közvetett haszna az, hogy csökkentik egy sikeres szkriptbefecskendezés esélyét, így segíthetik megőrizni az oldal megbízhatóságát a látogatók, a keresők és az AI-asszisztensek szemében. A fordított irányra is figyelj. Ha a CSP a saját megjelenítő szkriptjeidet blokkolja, a keresőrobot is hiányos oldalt láthat, ezért élesítés után nézd meg a Search Console URL-ellenőrzőjében a renderelt változatot. Helyezést vagy idézettséget egyik beállítás sem garantál.

Mit ellenőrizz élesítés után?

Az élesítés utáni ellenőrzés azt igazolja, hogy a fejlécek minden választípusra rákerültek, és közben semmi nem tört el. A lista tíz perc alatt végigjárható.

• A fejlécek megjelennek a főoldalon, egy aloldalon, a 404-es oldalon és egy statikus fájlon.
• Bejelentkezés nélkül, gyorsítótárból kiszolgált oldalon is ott vannak.
• A böngésző konzolja nem jelez CSP-sértést a legfontosabb oldaltípusokon.
• A GA4 valós idejű nézete mutatja a saját látogatásodat, a Tag Manager előnézete pedig az elsülő címkéket.
• Egy tesztűrlap elmegy, a konverzió megérkezik a hirdetési fiókba.
• A chat, a térkép, a videó és a süti-hozzájárulási sáv megjelenik és működik.
• A WordPress-admin, az oldalépítő és a médiatár hibátlanul használható.
• Ugyanaz a fejléc nem érkezik kétszer, eltérő értékkel.

Új bővítmény, új mérőkód vagy sablonváltás után ismételd meg az ellenőrzést, mert a CSP engedélyezőlistája nem követi magától a változásokat.

Források és további olvasnivalók

• MDN Web Docs: HTTP-fejlécek referenciája (Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy)
• W3C: Content Security Policy Level 3, Referrer Policy és Permissions Policy specifikáció
• IETF RFC 6797: HTTP Strict Transport Security
• OWASP Secure Headers Project és OWASP HTTP Headers Cheat Sheet
• Google Search Central: a HTTPS mint rangsorolási jel, JavaScript-alapú oldalak renderelése
• Google Tag Platform dokumentáció: Content Security Policy útmutató a Tag Managerhez és a GA4-hez
• Cloudflare dokumentáció: HSTS-beállítás és válaszfejléc-módosító szabályok
• WordPress Developer Resources: a send_headers művelet és a wp_headers szűrő
• Apache HTTP Server dokumentáció (mod_headers) és Nginx dokumentáció (add_header)