--- title: "WordPress biztonság" url: "https://wphu.org/alapok/wordpress-biztonsag/" date: "2026-01-16" modified: "2026-01-29" author: "Rottenbacher Tamás" language: "hu_HU" excerpt: "A WordPress biztonságos és nem egyetlen funkció, beállítás vagy bővítmény kérdése. Egy szemlélet és gyakorlat, amit bemutatunk cikkünkben." --- # WordPress biztonság A WordPress biztonság nem egyetlen funkció, beállítás vagy bővítmény kérdése. Sokkal inkább **egy szemlélet és folyamatos gyakorlat**, amelynek célja az, hogy egy weboldal **ellenálló legyen a támadásokkal, visszaélésekkel és kód fertőzésekkel szemben**. ## Biztonságos a WordPress? Fontos megérteni egy alapvető tényt: **A WordPress önmagában nem veszélyes, sőt kifejezetten biztonságos rendszer**. A WordPress core fejlesztését egy nemzetközi, hatalmas fejlesztői közösség végzi, amely folyamatosan javítja a hibákat és gyorsan reagál a biztonsági problémákra. A WordPress-nek külön Security csoportja van, a biztonság ellenőrzésére. A gondok túlnyomó többsége a **használat módjából** erednek. Ezért is készült ezen cikk, aminek az elolvasása erősen ajánlott. A WordPress biztonság megértése **nem csak fejlesztőknek fontos**, hanem minden weboldal tulajdonosnak, aki adatokat kezel, ügyfelekkel kommunikál, vagy használja a wordpress.org-os WP rendszerét. A cikk **legfontosabb részéhez nem szükséges programozási, informatikai tudás**! **Tartalomjegyzék** ## Mit jelent egy WordPress oldal „feltörése”? Sokan azt gondolják, hogy egy feltört weboldal azonnal látványos jeleket mutat: idegen tartalom, átirányítás más oldalra, vagy figyelmeztetés a böngészőben. Ez azonban csak a legsúlyosabb esetek egy része. Valójában egy WordPress oldal lehet úgy is kompromittált, hogy: - a látogatók semmit nem vesznek észre; - a támadó rejtett admin fiókot hoz létre; - a szerver spam leveleket küld; - SEO spam kerül az oldalba (rejtett linkek, kulcsszavak); - adatokat szivárogtat (felhasználói e-mailek, jelszó hash-ek). Ez különösen veszélyes, mert az ilyen „csendes” fertőzések **hónapokig észrevétlenek maradhatnak**, miközben komoly reputációs és jogi kockázatot jelentenek. A legtöbb feltörés mögött: - elavult bővítmények, - gyenge jelszavak, - rossz jogosultsági beállítások, - vagy nem megfelelő szerverkonfiguráció áll. ## Alapfogalmak, amelyeket érdemes tisztázni ### Mi az a sebezhetőség? Sebezhetőségnek nevezünk minden olyan hibát vagy hiányosságot, amely lehetővé teszi, hogy egy támadó **nem várt módon férjen hozzá a rendszerhez**, vagy olyan műveletet hajtson végre, amelyhez nem lenne joga. Ez lehet: - programozási hiba, - hiányzó ellenőrzés, - rosszul konfigurált beállítás, - vagy emberi mulasztás. ### Mi az a támadási felület? A támadási felület azoknak a pontoknak az összessége, ahol egy weboldal „érintkezik a külvilággal”. Ilyen például: - a bejelentkezési oldal, - az űrlapok, - az XML-RPC, - a REST API, - a fájlfeltöltési lehetőségek. A WordPress biztonság egyik alapelve: **minél kisebb a támadási felület, annál kisebb a kockázat**. ## Az 5 leggyakoribb WordPress támadási módok ### 1. Brute force támadások Ez a legegyszerűbb, de még mindig rendkívül gyakori módszer. A támadó automatizált eszközökkel próbálja végig: - a leggyakoribb felhasználóneveket, - a leggyengébb jelszavakat. Ha a jelszó gyenge, vagy az admin felhasználónév „admin”, a siker esélye drámaian megnő. ### 2. Elavult bővítmények kihasználása A legtöbb WordPress sebezhetőség bővítményekhez kapcsolódik. Így ez kritikusan fontos a biztonság szempontjából. Egy régi verziós plugin: - ismert hibát tartalmazhat, - publikus exploit állhat hozzá rendelkezésre, - automatizált szkriptek célpontja lehet. ### 3. Cross-Site Scripting (XSS) Az XSS során a támadó rosszindulatú JavaScript kódot juttat be az oldalba, amely: - ellophatja a felhasználók sütijeit, - átirányíthatja a látogatókat, - admin jogosultságot szerezhet. Ez gyakran űrlapoknál vagy kommenteknél fordul elő, ha nincs megfelelő adatellenőrzés. ### 4. Jogosultsági hibák kihasználása Ha egy bővítmény vagy téma nem megfelelően ellenőrzi, hogy egy felhasználó mit csinálhat, akkor: - egy egyszerű felhasználó admin funkciókhoz férhet hozzá, - beállításokat módosíthat, - fájlokat tölthet fel. ### 5. Rosszindulatú fájlfeltöltés Ez az egyik legsúlyosabb kategória. Ha egy támadó képes: - PHP fájlt feltölteni, - majd azt futtatni, akkor gyakorlatilag **teljes irányítást szerezhet** az oldal felett. ## Top 10 WordPress biztonsági hiányosság 1. Frissítések elhanyagolása 2. Gyenge jelszavak használata 3. „admin” felhasználónév alkalmazása 4. Nem megbízható forrásból származó bővítmények 5. HTTPS hiánya 6. XML-RPC indokolatlan engedélyezése 7. Biztonsági mentések hiánya 8. Felesleges, nem használt bővítmények 9. Rossz fájl- és mappajogosultságok 10. Szerveroldali alapvédelem hiánya Ezek többsége **nem technikai hiba**, hanem felhasználói döntés vagy odafigyelés hiányának a kérdése. ## Alapvető biztonsági lépések WordPress-hez Ezek azok a lépések, amelyeket **már a weboldal tulajdonosa vagy adminisztrátora is el és érdemes is figyelembe venni**, hogy a szerver konfigurációkba ne kellene nyúlnia. - **Erős jelszavak és kétlépcsős azonosítás**: Az admin felület védelmének első vonala a minőségi hitelesítés, amely jelentősen csökkenti a brute force kockázatot. - **Felhasználói szerepkörök racionalizálása**: Csak azoknak adj admin jogosultságot, akiknek tényleg szükséges; másoknak legyen korlátozottabb [szerepkör](https://wphu.org/alapok/szerepkorok-es-jogosultsagok/). Ha szükséges, csak ideiglenesen kapjon szükségesnél magasabb szerepkört. - **Legkevesebb szükséges plugin használata**: Minden plugin potenciális sebezhetőséget jelent; ezért csak a nélkülözhetetleneket tartsd fenn és frissítsd őket folyamatosan. ## A legfontosabb megelőző teendők – útmutató **Az 1. és 2. pontot mindenképpen vegyük komolyan**, mivel ezek elvégzésével jelentősen javíthatunk wordPress honlapunk, [WooCommerce webáruházunk](https://wphu.org/woocommerce-webaruhaz/) biztonságán. 1. **WordPress, bővítmények és sablonok rendszeres frissítése** A frissítések nem csak új funkciókat hoznak, hanem zárják az ismert hibákat és réseket is, amelyeket automatizált támadók próbálnak kihasználni. 2. **Erős, egyedi admin felhasználónév és jelszó használata** Az alapértelmezett „admin” és gyenge jelszavak bruteforce támadások célpontjai; ezek megnehezítik a jogosulatlan belépést. 3. **HTTPS használata minden oldalon (SSL/TLS)** A HTTPS titkosítja a kommunikációt, megakadályozza, hogy az adataid (pl. jelszó) lehallgathatók legyenek nyilvános hálózaton is. 4. **Megbízható tárhelyszolgáltató választása** Egy jó szolgáltató rendszeresen frissíti a szerver szoftvereket, megfelelő tűzfalat és karbantartást biztosít, így a szerveroldali sebezhetőségek esélye csökken. 5. **Biztonsági mentések rendszeres készítése** Mentések nélkül egy sikeres támadás esetén az oldalad visszaállítása nagyon nehéz lehet; érdemes külön szerverre/szolgáltatásba exportálni a mentéseket. 6. **Felesleges vagy inaktív bővítmények törlése** Még inaktív plugin is hordozhat kódot, amely hibát tartalmazhat; ezért csak azt tartsd, amit valóban használsz. 7. **Gyenge FTP/WebDAV programok kerülése** A nem biztonságos FTP‑kliensek jelszót vagy hitelesítő adatokat tárolhatnak rosszul, amelyeket helyi malware is kihasználhat. (Illetve sima FTP-t ne használjunk, helyette sFTP-vel kapcsolódjunk.) 8. **Az alapértelmezett tábla előtag (wp_) módosítása az adatbázisban** Az elterjedt wp_ előtagot kihasználó támadások egyszerűbbé teszik a WordPress ID‑k és táblák felismerését; egyedi előtag csökkenti ezt a lehetőséget. 9. **Fájl‑ és mappajogosultságok helyes beállítása** Olyan jogosultságokat állíts be (pl. 644/755), amelyek minimalizálják, hogy illetéktelenek írhassanak vagy módosíthassanak fájlokat. 10. **Biztonsági hibák és hibaüzenetek elrejtése a belépési felületen** A hibaüzenetek gyakran túl sok információt adnak a támadónak. Ezek elrejtésével megnehezíthetjük a jogosulatlan feletti diagnosztizálást. ## WordPress szerveroldali védelem növelése A most következő szekcióban **kifejezetten a szerveroldalt érintő védekezéseket** tárgyaljuk, mert ezek a WordPresshez kapcsolódó legfontosabb „hardening” lépések. A megközelítésünk az, hogy **tudatosan minimális támadási felületet hagyjunk maga körül** — tehát ne csak az alkalmazást (WordPress), hanem a webkiszolgálót is keményítsük. A szabályok alapesetben két fő webszerver‑típusra alkalmazhatók: **Apache** és **nginx**. ### Apache / .htaccess alapú védelem Az Apache szerverek .htaccess konfigurációs fájljai lehetővé teszik, hogy mappaszintű szabályokat alkalmazzunk anélkül, hogy a szerver teljes főkonfigurációját módosítanánk. A Rotisoft cikk több ilyen kódot is javasol. **1. wp‑config.php elrejtése**\ Ez megakadályozza, hogy a konfigurációs fájl közvetlenül böngészőn keresztül elérhető legyen. ``` # wp-config.php védelme order allow,deny deny from all ``` **2. Mappa indexelés tiltása**\ Megakadályozza, hogy külső látogatók (vagy támadók) a könyvtárak tartalmát listázzák. ``` # Mappa indexelés tiltása Options -Indexes ``` **3. IndexIgnore konfiguráció**\ További fájltípusok elrejtése a mappalistázásnál: ``` # Mappa listázás finomítása ha megis engedelyezve lenne IndexIgnore *.php *.js *.log *.zip *.tar *.gz *.sql *.bak *.old *.backup *.tmp *.conf *.ini *.env *.yml *.yaml *.json .git .gitignore .gitattributes ``` **4. XML‑RPC tiltása**\ Az XML‑RPC sok brute force és API‑t használó támadás célpontja lehet, ezért gyakran érdemes letiltani, ha nincs rá szükség. ``` # XML‑RPC tiltása Require all denied ``` **5. Egyszerű XSS / URL szűrés .htaccess‑szel**\ Ez a szabály megakadályoz bizonyos típusú rosszindulatú szkriptkódok továbbadását az URL‑ben — egy egyszerű első védelmi vonal lehet, de nem helyettesíti a teljes alkalmazás‑szintű validációt. Ezt ellenőrizni kell, mert egyes pluginek érzékenyek lehetnek rá. ``` # Egyszerű XSS szűrés Options +FollowSymLinks RewriteEngine On RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0‑9A‑Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0‑9A‑Z]{0,2}) RewriteRule ^(.*)$ index.php [F,L] ``` **6. Admin elérhetőség IP‑limitálással**\ Ha fix IP‑címed van, ezzel csak a saját címed engedélyezheted a /wp‑admin mappához. ``` # Admin IP korlátozás pelda ip-vel order deny,allow allow from 111.1.111.1 deny from all ``` Ezek a példapéldányok a Rotisoft cikkből származó, kézzel szerkeszthető .htaccess minták és tanácsok alapján állnak össze. ### Nginx‑es szabályok Az nginx nem használ .htaccess‑t, ezért minden szabályt **a szerverkonfigurációban (pl. nginx.conf vagy a vhost konfigurációban)** kell elhelyezni. A következő minták hasonló védelmet nyújtanak az Apache‑os példákhoz. **1. wp‑config.php elrejtése** ``` location ~* wp-config.php { deny all; } ``` **2. Mappa indexelés tiltása** ``` autoindex off; ``` **3. XML‑RPC tiltása** ``` location = /xmlrpc.php { deny all; return 403; } ``` **4. Egyszerű XSS kérésblokkolás** Ennél szintén ellenőrizzük a bővítményeket, mert érzékenyek lehetnek rá. ``` if ($query_string ~* "