WordPress biztonság: a hét alapvető beállítás

Scheo · 2026-08-05 · Frissítve: 2026-09-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A WordPress a világ legelterjedtebb tartalomkezelő rendszere, és pont ezért a legkedveltebb célpont is. Nem azért támadják az oldalad, mert érdekes vagy, hanem mert egy szkript automatikusan végigpásztázza az interneten a WordPress-telepítéseket, és ahol talál egy elavult bővítményt vagy egy gyenge jelszót, ott megpróbál bejutni. Ez a cikk azt a hét beállítást veszi végig, amit minden WordPress oldalon érdemes elvégezni, függetlenül attól, hogy egy egyszemélyes vállalkozás bemutatkozó oldaláról vagy egy több szerkesztős webáruházról van szó.

Miért támadják egyáltalán a te WordPress oldaladat?

Rövid válasz: a legtöbb WordPress feltörés nem célzott, hanem automatizált. Botok tömegesen keresik a sebezhető telepítéseket, és a feltört oldalt spamküldésre, átirányításra, kártékony kód terjesztésére vagy más oldalak elleni támadásra használják.

Tovább a témában: Milyen karbantartást igényel egy wordpress weboldal hosszú távon? · WordPress karbantartás Salgótarján

Ebből következik a legfontosabb gondolat: nem kell nagy cégnek lenned ahhoz, hogy támadás érjen. A tapasztalatunk (saját tapasztalat, ügyfélneveket nem sorolunk) az, hogy a kis, egyszemélyes oldalak sokszor sérülékenyebbek, mert ott nincs, aki figyelje a frissítéseket. A támadó pedig nem az adataidra hajt, hanem a szerver erőforrására és az oldalad domain-jének jó hírére.

Hivatalos információ: a WordPress projekt a wordpress.org oldalán tartja karban a hivatalos biztonsági dokumentációt (Hardening WordPress), és a sebezhetőségekről a WordPress Security Team ad ki tájékoztatást. Érdemes ezt tekinteni kiindulási alapnak, nem egy-egy bővítménygyártó marketinganyagát.

Hogyan állítsd be a jelszavakat és a jogosultságokat?

Rövid válasz: minden felhasználónak egyedi, legalább 16 karakteres, jelszókezelőben tárolt jelszava legyen, kétlépcsős azonosítással, és mindenki csak annyi jogot kapjon, amennyi a munkájához kell.

Lépésről lépésre:

1. Nézd végig a Felhasználók menüpontot, és töröld vagy fokozd le azokat a fiókokat, amiket már senki nem használ. A régi fejlesztői admin fiók a leggyakoribb hátsó ajtó.
2. Az admin felhasználónevet ne használd. Ha van ilyen fiókod, hozz létre egy új adminisztrátort más névvel, jelentkezz be vele, majd töröld a régit, és a tartalmát rendeld hozzá az új fiókhoz.
3. Oszd szét a szerepköröket: a szerkesztő, aki csak cikkeket ír, kapjon Szerző vagy Szerkesztő jogot, ne adminisztrátort. Adminisztrátori jogot csak az kapjon, aki bővítményt telepít.
4. Vezess be kétlépcsős azonosítást (2FA) legalább az adminisztrátori fiókokra. Erre több ingyenes, jó karbantartású bővítmény létezik, ami TOTP-alapú kódokkal (Google Authenticator, Authy) működik.
5. Használj jelszókezelőt (Bitwarden, 1Password, KeePass). A jelszó megosztása chatben vagy e-mailben ma már nem elfogadható gyakorlat.

Szakmai feltételezés: a legtöbb kisvállalkozásnál a leggyorsabban megtérülő biztonsági lépés a 2FA bekapcsolása, mert egyetlen kiszivárgott jelszó önmagában így már nem elég a bejutáshoz. Ez nem garantál sérthetetlenséget, de a botok elleni védelemben nagyot javít.

Milyen frissítési rutint érdemes kialakítani?

Rövid válasz: a WordPress mag és a biztonsági javítások menjenek automatikusan, a bővítmények és a sablon frissítése pedig legyen ütemezett, mentés utáni, ellenőrzött rutin, legalább havonta.

A sikeres feltörések nagy része nem a WordPress magját, hanem elavult bővítményeket és sablonokat használ ki. Ezért a frissítés nem kényelmi kérdés, hanem az egyik legerősebb védelmi eszköz.

A gyakorlati sorrend, amit érdemes követni:

1. Mentés a frissítés előtt (adatbázis és fájlok együtt).
2. Először a WordPress mag, aztán a sablon, végül a bővítmények.
3. Frissítés után ellenőrizd a kritikus funkciókat: kapcsolati űrlap, kosár, pénztár, bejelentkezés, keresés.
4. Ha valami elromlik, állítsd vissza az adott bővítmény korábbi verzióját, ne az egész oldalt.

A biztonsági (minor) frissítéseket a WordPress alapból automatikusan telepíti. A fő verziók automatizálását a wp-config.php fájlban tudod szabályozni:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Ez a beállítás a biztonsági és karbantartási frissítéseket engedi, a nagy verzióugrást viszont rád bízza. Nagyobb, egyedi fejlesztésekkel teli oldalnál ez általában biztonságosabb, mint a teljes automatizálás.

Külön figyelj arra, hogy törölj minden nem használt bővítményt és sablont. Egy deaktivált, de telepítve hagyott bővítmény kódja továbbra is ott van a szerveren, és sérülékenység esetén támadási felület marad.

Mitől lesz a mentés valóban használható?

Rövid válasz: attól, hogy automatikus, a weboldal tárhelyétől független helyre kerül, több visszamenőleges verziót őriz, és időnként tényleg vissza is állítottátok belőle az oldalt.

A leggyakoribb hiba, amivel találkozunk (saját tapasztalat): a mentés ugyanazon a tárhelyen van, mint az oldal. Ha a szervert éri a baj, vagy egy kártevő végigmegy a fájlrendszeren, a mentés is odaveszik.

Ellenőrzőlista a mentéshez:

• Az adatbázis és a fájlok (wp-content, feltöltések, sablon) is benne vannak.
• A mentés külső helyre megy: Google Drive, Dropbox, S3-kompatibilis tároló vagy külön szerver.
• Legalább 7-14 nap visszamenőleges verzió elérhető, mert egy fertőzést sokszor csak napokkal később vesznek észre.
• A mentés automatikus, nem kézi. Ami kézi, azt előbb-utóbb elfelejtitek.
• Évente legalább egyszer teszt-visszaállítás egy ideiglenes (staging) környezetbe. Ez a lépés, amit szinte mindenki kihagy.

A gyakoriságot a tartalom változásához igazítsd: egy statikus bemutatkozó oldalnál heti mentés is elég lehet, egy naponta rendelést fogadó webáruháznál viszont a napi (vagy valós idejű) mentés az elvárható minimum.

Mit csinál a tűzfal, és milyen szintre tedd?

Rövid válasz: a webalkalmazás-tűzfal (WAF) még azelőtt kiszűri a gyanús kéréseket, hogy azok elérnék a WordPress kódját, és a legjobb hatásfokot a szerver vagy a DNS szintjén futó megoldás adja.

Három szintje van, ezek egymást kiegészítik:

• DNS-szintű tűzfal (például Cloudflare): a forgalom hozzájuk fut be, és a rossz kérés el sem jut a tárhelyedig. Ez fogja meg a legtöbb terhelést.
• Szerveroldali tűzfal: a tárhelyszolgáltató biztosítja (gyakran ModSecurity szabályrendszerrel). Érdemes rákérdezni, hogy be van-e kapcsolva.
• Bővítmény-szintű tűzfal: a WordPressen belül fut. Kényelmes, de a kérés ekkorra már betöltötte a PHP-t, tehát a terhelés ellen kevésbé véd.

Ha csak egyet tudsz bevezetni, kezdd a DNS-szintűvel, mert ott a legkisebb a teljesítménybeli ára. Emellett a tárhelyen érdemes megnézni, hogy a PHP-futtatás tiltva van-e a feltöltési mappában. Apache alatt ezt a wp-content/uploads könyvtárba tett .htaccess szabállyal lehet elérni:

<Files *.php>deny from all</Files>

Ezzel azt akadályozod meg, hogy egy feltöltött, PHP-nak álcázott fájl lefusson. Nginx alatt ugyanezt a szerverkonfigurációban kell megoldani, ezért ott kérd a szolgáltató segítségét.

Hogyan védd meg a bejelentkezési oldalt?

Rövid válasz: korlátozd a sikertelen bejelentkezési kísérletek számát, kapcsold ki a felesleges belépési felületeket, és ha teheted, szűkítsd IP-cím alapján az admin felület elérését.

A wp-login.php a legtöbbet támadott pont egy WordPress oldalon. Amit érdemes megtenni:

1. Kísérletkorlátozás: 3-5 hibás próbálkozás után átmeneti tiltás. Ezt szinte minden biztonsági bővítmény tudja, és önmagában a brute force kísérletek túlnyomó részét megállítja.
2. Hibaüzenet elrejtése: alapból a WordPress elárulja, hogy a felhasználónév létezik-e. Ezt érdemes egységes, semmitmondó üzenetre cserélni.
3. XML-RPC: ha nem használod (nem publikálsz mobilappból, nincs Jetpack vagy külső integráció), tiltsd le a xmlrpc.php elérését. Ezen keresztül a támadó egyetlen kéréssel több száz jelszót is végigpróbálhat.
4. Bejelentkezési URL megváltoztatása: ez nem valódi védelem, csak zaj-csökkentés (security through obscurity), de a naplókat átláthatóbbá teszi. Önmagában ne bízz benne.
5. Felhasználó-felsorolás tiltása: a ?author=1 típusú lekérdezés és a REST API felhasználó-végpontja kifelé is megmutathatja a bejelentkezési neveket.

Ha az oldalt egy fix irodai IP-címről szerkesztitek, a legerősebb megoldás az admin könyvtár IP-alapú szűkítése. Otthonról dolgozó, változó IP-jű csapatnál ez viszont folyamatos bosszúság forrása, tehát mérlegelj.

Elég-e önmagában az SSL tanúsítvány?

Rövid válasz: nem elég, de nélkülözhetetlen. Az SSL a böngésző és a szerver közötti adatforgalmat titkosítja, tehát a jelszavad nem utazik olvasható formában, viszont a feltört bővítmény ellen nem véd.

A helyes beállítás lépései:

1. Kérj tanúsítványt (a Let's Encrypt ingyenes, és a legtöbb tárhelyen egy kattintás).
2. Állítsd be a teljes oldalra a HTTPS-t: a Beállítások > Általános menüben a WordPress-cím és a webhelycím is https:// legyen.
3. Készíts 301-es átirányítást HTTP-ről HTTPS-re, hogy ne legyen kettős elérés.
4. Javítsd a vegyes tartalmat (mixed content): a régi cikkekben maradt http:// hivatkozásokat cseréld le. Erre használható a WP-CLI keresés-csere parancsa, de mentés után futtasd.
5. Ha stabilan működik, kapcsold be a HSTS fejlécet. Ez a böngészőnek szól, hogy az oldalt csak HTTPS-en keresse.

Az SSL ma alapelvárás: a böngészők figyelmeztetést jelenítenek meg a titkosítatlan oldalakon, ez pedig közvetlenül rontja a bizalmat és a konverziót. A Google hivatalos álláspontja szerint a HTTPS egy könnyű rangsorolási jelzés, de a valódi haszna a felhasználói bizalom és az adatvédelem.

Mit jelent a folyamatos felügyelet a gyakorlatban?

Rövid válasz: azt, hogy nem akkor tudod meg a bajt, amikor egy ügyfél telefonál. Elérhetőség-figyelés, fájlváltozás-figyelés, naplózás és havi átnézés együtt adja ki.

Minimum, amit érdemes beállítani:

• Uptime-figyelés: percenkénti ellenőrzés, e-mail vagy push riasztással, ha az oldal nem válaszol.
• Fájlintegritás-ellenőrzés: a biztonsági bővítmény összeveti a WordPress mag és a bővítmények fájljait a hivatalos verzióval, és szól, ha eltérés van. Ez árulja el leggyorsabban a beépült hátsó ajtót.
• Google Search Console: a Biztonsági problémák riport jelzi, ha a Google kártékonynak találta az oldalt. Ez hivatalos információ, közvetlenül a keresőtől.
• Naplózás: ki, mikor, mit módosított. Több szerkesztős oldalnál ez nem paranoia, hanem alap üzemeltetési igény.
• Havi átnézés: frissítések, felhasználólista, mentés-teszt, naplók átfutása. Kb. 20-30 perc, és megelőzi a hétvégi tűzoltást.

Milyen ellenőrzőlistával tudod végigvinni mind a hetet?

Rövid válasz: haladj felülről lefelé, és amit ma nem tudsz megcsinálni, azt írd be a naptáradba dátummal. A félkész biztonság a legveszélyesebb, mert hamis biztonságérzetet ad.

• Nincs admin nevű felhasználó, és minden inaktív fiók törölve.
• Minden fiók egyedi, hosszú jelszót használ, jelszókezelőben tárolva.
• Az adminisztrátori fiókokon aktív a kétlépcsős azonosítás.
• A jogosultságok szerepkör szerint szűkítve, nem mindenki admin.
• A WordPress mag biztonsági frissítései automatikusak.
• Minden bővítmény és sablon naprakész, a nem használtak törölve.
• Automatikus mentés fut, külső tárhelyre, több visszamenőleges verzióval.
• A visszaállítás legalább egyszer tesztelve volt.
• Aktív tűzfal (DNS- vagy szerverszinten), PHP-futtatás tiltva a feltöltési mappában.
• Bejelentkezési kísérletek korlátozva, XML-RPC letiltva, ha nincs rá szükség.
• Érvényes SSL tanúsítvány, teljes HTTPS, vegyes tartalom nélkül.
• Uptime- és fájlváltozás-figyelés bekapcsolva, riasztás valós e-mail címre.
• Search Console beállítva, a biztonsági riport rendszeresen ellenőrizve.
• Van egy leírt terv arra, mi történik, ha az oldal mégis feltörik: kit hívsz, honnan állítod vissza.

Ez a lista nem tesz sérthetetlenné egyetlen oldalt sem, és nem is ígér ilyet. Amit jó eséllyel elér: a tömeges, automatizált támadások túlnyomó része már az első akadálynál elakad, a maradék pedig gyorsabban észrevehető és javítható lesz. Egy célzott, felkészült támadó ellen ennél többre van szükség, de a kisvállalkozói weboldalak valós kockázata nem ez.

Ha van fejlesztőd vagy üzemeltetőd, ezt az ellenőrzőlistát nyugodtan küldd át neki, és kérd, hogy pontonként jelezze vissza az állapotot. Ha nincs, akkor is végig tudod menni: a hét pont közül öt kattintásokkal megoldható, kettő (tűzfal és szerverszintű beállítás) igényel általában külső segítséget.

Források és további olvasnivalók

• WordPress.org: Hardening WordPress (hivatalos fejlesztői dokumentáció)
• WordPress.org: Updating WordPress és a WordPress Security Team közleményei
• Google Search Central: HTTPS as a ranking signal, valamint a Search Console Biztonsági problémák súgója
• OWASP: Top Ten és az Authentication Cheat Sheet
• NIST Special Publication 800-63B: Digital Identity Guidelines (jelszószabályok)
• Let's Encrypt hivatalos dokumentáció (tanúsítvány kiállítása és megújítása)
• Mozilla Developer Network (MDN): Strict-Transport-Security (HSTS) leírás
• Cloudflare Learning Center: What is a WAF?