A WordPress a web hatalmas részét működteti, ami állandó célponttá teszi. A jó hír, hogy a WordPress-feltörések túlnyomó többsége a gyengeségek egy kicsi, kiszámítható halmazát használja ki, és szinte mindegyik megelőzhető. Ez a WordPress biztonsági megerősítés ellenőrzőlista végigvezet azokon a lépéseken, amelyek 2026-ban valóban számítanak, nagyjából fontossági sorrendben.

Röviden

  • A sérülékeny és elavult bővítmények és sablonok jelentik a legnagyobb WordPress támadási felületet; a fegyelmezett frissítések és a nem használt kód eltávolítása mindennél többet számít
  • Az erős hitelesítés (egyedi rendszergazdai felhasználónevek, erős jelszavak, kétfaktoros hitelesítés, bejelentkezési sebességkorlátozás) zárja be a második leggyakoribb ajtót
  • Erősítse meg a wp-config.php fájlt, a fájljogosultságokat és a REST API / XML-RPC felületet, és tegyen WAF-ot az oldal elé
  • Készítsen rendszeres mentéseket és tesztelje a visszaállítást; egy jó mentés a betörést kellemetlenséggé teszi katasztrófa helyett

1. Tartsa naprakészen a rendszermagot, a bővítményeket és a sablonokat

Az elavult bővítmények és sablonok a WordPress-oldalak feltörésének első számú módja. Minden bővítmény harmadik féltől származó kód, amely hozzáféréssel fut az oldalához.

  • Engedélyezze a WordPress rendszermag automatikus frissítéseit (legalább a kisebb kiadásoknál).
  • Frissítse a bővítményeket és sablonokat időben, ideális esetben ütemezetten, teszttel egy staging környezetben.
  • Távolítsa el azokat a bővítményeket és sablonokat, amelyeket nem használ. A deaktiválás nem elég; a törlés biztonságos.
  • Csak megbízható forrásból telepítsen bővítményeket, aktív karbantartási előzményekkel.
  • Figyelje az elhagyott bővítményeket; a nem karbantartott kód kockázat, még ha működik is.

2. Zárja le a hitelesítést

A wp-login.php elleni brute-force és hitelesítőadat-alapú támadások szüntelenek.

  • Soha ne használja az admin felhasználónevet. Használjon egyedi rendszergazdai nevet.
  • Kényszerítsen ki erős, egyedi jelszavakat minden fiókhoz.
  • Engedélyezze a kétfaktoros hitelesítést (2FA) minden rendszergazdai és szerkesztői fióknál.
  • Korlátozza a bejelentkezési kísérleteket, és adjon hozzá sebességkorlátozást a brute-force kísérletek blokkolásához.
  • Fontolja meg a bejelentkezési URL módosítását vagy védelmét és egy CAPTCHA kihívás hozzáadását.

3. Alkalmazza a legkisebb jogosultság elvét a felhasználói szerepköröknél

  • Adja meg minden felhasználónak a legalacsonyabb szerepkört, amely lehetővé teszi a munkáját. Nem mindenkinek kell rendszergazdának lennie.
  • Rendszeresen auditálja a felhasználói fiókokat, és távolítsa el a volt munkatársakat és a nem használt bejelentkezéseket.
  • Vizsgálja felül a szerepköröket olyan bővítmények telepítése után, amelyek egyedi képességeket adnak hozzá.

4. Erősítse meg a wp-config.php fájlt

A wp-config.php tárolja az adatbázis-hitelesítő adatokat és a titkos kulcsokat, ezért különös figyelmet érdemel.

  • Állítson be egyedi hitelesítési kulcsokat és sókat (salt).
  • Tiltsa le a beépített fájlszerkesztőt: define('DISALLOW_FILE_EDIT', true);, így a rendszergazdai hozzáférést szerző támadó nem tudja szerkeszteni a sablon- és bővítménykódot a vezérlőpultról.
  • Helyezze a wp-config.php fájlt egy szinttel a webes gyökér fölé, ahol a tárhely megengedi, és korlátozza a fájljogosultságait.
  • Tartsa a WP_DEBUG beállítást kikapcsolva éles környezetben, hogy a hibák ne szivárogtassanak információt.

5. Állítson be helyes fájl- és könyvtárjogosultságokat

  • Könyvtárak 755, fájlok 644 alapértelmezett kiindulásként; soha ne használjon 777-et.
  • Gondoskodjon róla, hogy a webszerver felhasználója birtokolja a fájlokat, de ne írhasson oda, ahol nincs rá szükség.
  • Védje az érzékeny fájlokat, és tiltsa le a könyvtárböngészést.

6. Csökkentse a támadási felületet: XML-RPC és REST API

  • Tiltsa le az XML-RPC-t, ha nem használja; gyakori brute-force és DDoS-erősítési vektor.
  • Korlátozza vagy hitelesítse a REST API-t ott, ahol olyan adatokat tesz elérhetővé, amelyeket nem szeretne nyilvánossá tenni.
  • Távolítsa el a WordPress verziószámát és minden más szükségtelen információközlést az oldalkimenetből.

7. Tegyen WAF-ot és HTTPS-t az oldal elé

  • Szolgálja ki a teljes oldalt HTTPS-en keresztül, és irányítsa át az összes HTTP forgalmat.
  • Adjon hozzá biztonsági fejléceket (HSTS, X-Content-Type-Options, X-Frame-Options vagy egy frame-ancestors Content-Security-Policy, és egy CSP, ahol kivitelezhető).
  • Használjon webalkalmazás-tűzfalat. Egy CDN-szintű WAF, mint a Cloudflare, kiszűri a rosszindulatú forgalmat, mielőtt eléri a WordPresst, és elnyeli a bot- és DDoS-terhelést.

8. Adatbázis- és tárhely-megerősítés

  • Használjon nem alapértelmezett adatbázis-tábla előtagot az új telepítéseknél.
  • Használjon dedikált adatbázis-felhasználót, csak azokkal a jogosultságokkal, amelyekre a WordPressnek szüksége van.
  • Tartsa a PHP-t támogatott, aktuális verzión; a lejárt támogatású PHP csendes kockázat.
  • Válasszon olyan tárhelyet, amely elkülöníti az oldalakat és javítja a szerveroldali szoftverkészletet.

9. Felügyelet, mentések és helyreállítás

  • Futtasson kártevő- és fájlintegritás-ellenőrzést, hogy a váratlan változásokat gyorsan észlelje.
  • Engedélyezze a biztonsági naplózást, hogy lássa a bejelentkezési kísérleteket és a változtatásokat.
  • Készítsen rendszeres, automatikus mentéseket a szerveren kívül tárolva, és tesztelje a visszaállításukat. A nem tesztelt mentés remény, nem terv.

Legfontosabb tanulságok

  • A legnagyobb nyereségek nem látványosak: mindent frissíteni, eltávolítani a nem használt bővítményeket és sablonokat, és erős hitelesítést kikényszeríteni 2FA-val.
  • Erősítse meg a wp-config.php fájlt, a fájljogosultságokat és az XML-RPC / REST API felületet a támadási felület csökkentéséhez.
  • Tegyen HTTPS-t, biztonsági fejléceket és WAF-ot az oldal elé.
  • Készítsen rendszeres mentéseket és tesztelje a visszaállítást, hogy a betörés helyreállítható legyen.

Professzionális WordPress biztonsági megerősítés

Egy ellenőrzőlista a legtöbb utat megteszi, de a WordPress biztonsági megerősítés így is profitál a szakértői szemből. Egy WordPress biztonsági audit átvizsgál minden bővítményt és sablont, teszteli a hitelesítést és a hozzáférést, és ellenőrzi a wp-config.php fájlt, az adatbázist, valamint a REST API és XML-RPC felületet, priorizált megerősítési tervet készítve. A teljes oldalra és a technológiai készletre kiterjedő átfogó képért lásd a weboldal-biztonsági audit útmutatót brit vállalkozásoknak . Ha az oldalának a megerősítés mellett folyamatos fejlesztésre és karbantartásra is szüksége van, egy felvehető WordPress-fejlesztő hosszú távon biztonságban tarthatja.

Gyakran Ismételt Kérdések (GYIK)

Hogyan törik fel leggyakrabban a WordPress-oldalakat? Sérülékeny és elavult bővítményeken és sablonokon keresztül. A harmadik féltől származó bővítménykód a legnagyobb támadási vektor, ezért a gyors frissítések és a nem használt bővítmények eltávolítása szinte mindennél többet számít.

Tényleg szükségem van biztonsági bővítményre? Egy megbízható biztonsági bővítmény segít a kártevőkeresésben, a bejelentkezés korlátozásában és a felügyeletben, de nem helyettesíti az alapokat: frissítések, erős hitelesítés, legkisebb jogosultságú szerepkörök és egy WAF. Alkalmazza a jó higiénia mellé, ne helyette.

Le kellene tiltanom az XML-RPC-t? Ha nem használja (például a mobilalkalmazáshoz vagy bizonyos integrációkhoz), akkor igen. Az XML-RPC-t gyakran visszaélik brute-force és DDoS-erősítés céljából, így a letiltása egy gyakori támadási felületet szüntet meg.

Milyen gyakran mentsem a WordPress-oldalamat? Elég gyakran ahhoz, hogy ne veszíthessen érdemi adatot, aktív oldalaknál jellemzően naponta, a szerveren kívül tárolva. Ami döntő: tesztelje a visszaállításokat; egy soha vissza nem állított mentés bizonyítatlan.

Elég a Cloudflare a WordPress biztonságához? Egy CDN-szintű WAF, mint a Cloudflare, sok rosszindulatú forgalmat kiszűr, és elnyeli a bot- és DDoS-terhelést, de nem javítja a sérülékeny bővítményeket, a gyenge jelszavakat vagy a hibás konfigurációt. Használja egyik rétegként a helyi megerősítés mellett.