A WordPress a világ egyik legelterjedtebb weboldal-kezelő rendszere, ezért nem meglepő, hogy a támadók egyik kedvelt célpontja is. Ez azonban nem jelenti azt, hogy a WordPress önmagában nem biztonságos. A legtöbb probléma nem abból ered, hogy WordPress működteti az oldalt, hanem abból, hogy elavult szoftverek, rosszul beállított jogosultságok, feleslegesen elérhető funkciók, gyenge jelszavak vagy nem megfelelően védett szerverek maradnak a rendszerben.
Egy professzionális WordPress-weboldal biztonságát ezért nem egyetlen biztonsági bővítmény adja. A megfelelő védelem több egymásra épülő rétegből áll.
Miért kell komolyan venni egy WordPress-weboldal biztonságát?
Egy feltört weboldal következményei jóval súlyosabbak lehetnek annál, mint hogy valaki átír egy oldalt.
Egy támadó például:
- hozzáférhet az adminisztrációhoz;
- rosszindulatú kódot helyezhet el az oldalban;
- átirányíthatja a látogatókat más weboldalakra;
- spam- vagy adathalász oldalakat hozhat létre;
- felhasználói adatokat szerezhet meg;
- módosíthatja vagy törölheti a weboldal tartalmát;
- új adminisztrátori felhasználót hozhat létre;
- feltölthet kártékony fájlokat;
- a weboldalt más támadások kiindulópontjaként használhatja;
- jelentősen ronthatja az oldal keresőmotoros megítélését.
Egy üzleti weboldal esetében ehhez még reputációs és pénzügyi kockázat is társul. Ha a Google vagy egy biztonsági szolgáltatás veszélyesnek jelöli az oldalt, az közvetlenül befolyásolhatja a látogatottságot és az ügyfélszerzést.
WooCommerce esetén a kockázat még nagyobb lehet, hiszen a rendszer vásárlási, rendelési és ügyféladatokat is kezel.
A WordPress biztonsága rétegekben gondolkodva
A jó biztonsági stratégia egyik legfontosabb alapelve, hogy ne egyetlen védelemre építsünk.
Érdemes legalább az alábbi rétegekben gondolkodni:
- szerver és tárhely biztonsága;
- WordPress core biztonsága;
- pluginok és témák biztonsága;
- adminisztrációs felület védelme;
- fájlok és jogosultságok védelme;
- hálózati és HTTP-szintű védelem;
- adatbázis és felhasználói adatok védelme;
- biztonsági mentések;
- monitorozás és rendszeres ellenőrzés.
Ha egy réteg hibázik, a többi rétegnek lehetőleg meg kell akadályoznia, hogy ebből teljes kompromittálódás legyen.
1. A WordPress és minden komponens naprakészen tartása
Az egyik legalapvetőbb biztonsági feladat a WordPress, a pluginok és a témák frissítése.
A WordPress core mellett különösen fontos a harmadik féltől származó bővítmények figyelése. Egy weboldal biztonsága ugyanis nem lehet erősebb, mint a leggyengébb, sérülékeny komponense.
Különösen veszélyesek lehetnek:
- régóta nem frissített pluginok;
- megszűnt fejlesztésű bővítmények;
- ismeretlen forrásból származó pluginok;
- feltört vagy módosított prémium pluginok;
- feleslegesen telepített, de nem használt bővítmények;
- régi témák és child theme-ek.
A „nincs aktiválva” és a „nincs telepítve” között biztonsági szempontból fontos különbség van. Amit már nem használunk, azt általában érdemes teljesen eltávolítani.
Miért veszélyesek a nulled pluginok?
A módosított, illegálisan terjesztett prémium pluginok különösen kockázatosak. Ezekben könnyen elrejthető:
- backdoor;
- malware;
- spamkód;
- adatlopó kód;
- jogosultságot megkerülő mechanizmus;
- távoli kódfuttatást lehetővé tevő funkció.
Egy üzleti weboldalon a néhány ezer forintos vagy akár ingyenes „prémium plugin” ezért rendkívül drága kockázattá válhat.
2. Erős adminisztrációs védelem
A WordPress adminisztrációs felülete kiemelt célpont.
Az első védelmi vonal a megfelelő felhasználói fiókkezelés.
Fontos:
- erős, egyedi jelszavak használata;
- minden adminisztrátornál külön felhasználói fiók;
- a felesleges felhasználók törlése;
- a jogosultságok minimalizálása;
- a kétlépcsős hitelesítés használata;
- az adminisztrátori hozzáférések rendszeres felülvizsgálata.
Nem érdemes minden felhasználónak adminisztrátori jogosultságot adni.
Egy szerkesztőnek általában nincs szüksége olyan jogosultságokra, amelyekkel pluginokat telepíthet vagy módosíthatja a weboldal rendszerbeállításait.
Kétlépcsős hitelesítés
A 2FA az egyik leghasznosabb extra védelem.
Ha valaki megszerzi a jelszót, önmagában még nem feltétlenül tud belépni, mert szüksége lesz a második hitelesítési tényezőre is.
Ez különösen fontos:
- adminisztrátori fiókoknál;
- WooCommerce-adminisztrátoroknál;
- fejlesztői hozzáféréseknél;
- tárhely- és hostingfiókoknál.
3. Brute-force támadások elleni védelem
A brute-force támadás során a támadó nagy mennyiségű bejelentkezési kísérlettel próbálja kitalálni a jelszót.
Ennek megakadályozására több módszer is használható:
- login rate limiting;
- sikertelen bejelentkezések korlátozása;
- CAPTCHA vagy alternatív botvédelem;
- IP-alapú blokkolás;
- WAF;
- 2FA;
- erős és egyedi jelszavak.
A cél nem feltétlenül az, hogy minden támadási kísérletet technikailag lehetetlenné tegyünk. Sokkal fontosabb, hogy a próbálkozások költsége és nehézsége jelentősen megnőjön.
4. A WordPress REST API megfelelő kezelése
A WordPress REST API számos modern funkció működéséhez szükséges, ezért teljes körű letiltása nem mindig jó ötlet.
Ugyanakkor érdemes átgondolni, hogy a weboldalnak valóban szüksége van-e minden publikus API-végpontra.
A cél nem az, hogy „mindent tiltsunk”, hanem az, hogy csak az legyen elérhető, amire ténylegesen szükség van.
Különösen fontos ellenőrizni:
- milyen adatok érhetők el hitelesítés nélkül;
- milyen pluginok használják az API-t;
- szükséges-e a külső alkalmazások számára;
- WooCommerce esetén mely API-funkciók szükségesek.
A túl agresszív REST API-tiltás viszont kompatibilitási problémákat okozhat, ezért ezt mindig az adott weboldal funkcióihoz kell igazítani.
5. XML-RPC és Pingback
A WordPress XML-RPC rendszere régebbi integrációs funkciókat támogat.
Ha egy weboldalnak nincs szüksége XML-RPC-re, biztonsági szempontból indokolt lehet a hozzáférés korlátozása vagy tiltása.
Különösen akkor érdemes megvizsgálni, ha az oldal nem használ olyan külső szolgáltatást vagy alkalmazást, amely XML-RPC-n keresztül kommunikál vele.
A pingback funkció szintén kikapcsolható, ha nincs rá szükség.
Fontos azonban, hogy itt se az legyen a cél, hogy automatikusan minden WordPress-funkciót letiltsunk. Először azt kell megvizsgálni, hogy az adott weboldal ténylegesen mit használ.
6. Felesleges WordPress-funkciók eltávolítása
Egy professzionálisan konfigurált WordPress-oldalon nem feltétlenül szükséges minden alapértelmezett funkciót meghagyni.
Ha például egy weboldal nem használ:
- kommenteket;
- pingbacket;
- XML-RPC-t;
- bizonyos feedeket;
- RSD endpointot;
- felesleges metaadatokat;
- szükségtelen REST API-hozzáféréseket;
akkor ezek megfelelő korlátozása csökkentheti az oldal támadási felületét.
Ez azonban nem pusztán „biztonsági takarítás”. A cél a támadási felület tudatos csökkentése.
7. A wp-config.php védelme
A wp-config.php a WordPress egyik legérzékenyebb fájlja.
Többek között adatbázis-hozzáférési adatokat és biztonsági kulcsokat tartalmazhat.
Ezért fontos:
- megfelelő fájljogosultság;
- szerveroldali védelem;
- a fájl közvetlen HTTP-hozzáférésének megakadályozása;
- erős adatbázis-jelszó;
- a biztonsági kulcsok megfelelő kezelése.
A wp-config.php esetében különösen fontos, hogy a webkiszolgáló soha ne szolgáltassa ki annak tartalmát a látogatóknak.
8. Fájljogosultságok
A túl megengedő fájljogosultságok komoly biztonsági problémát jelenthetnek.
Általános kiindulási pontként gyakran:
- fájlok:
644; - könyvtárak:
755; - érzékeny konfigurációs fájlok: szigorúbb jogosultság.
A pontos érték azonban függ a hosting környezetétől és attól is, hogy milyen felhasználó alatt fut a PHP.
A túl szigorú jogosultságok ugyanakkor működési problémákat okozhatnak. Nem az a cél, hogy mindenre automatikusan 600 vagy 640 kerüljön, hanem hogy minden fájl csak a szükséges hozzáférést kapja.
Ez az úgynevezett least privilege, vagyis a legkisebb szükséges jogosultság elve.
9. HTTPS és TLS
Ma már egy üzleti WordPress-oldalon a HTTPS alapkövetelmény.
A HTTPS:
- titkosítja a kliens és a szerver közötti kommunikációt;
- védi a bejelentkezési adatokat;
- védi az űrlapokon továbbított adatokat;
- növeli a látogatói bizalmat;
- szükséges számos modern webes funkcióhoz.
Nem elég azonban pusztán SSL-tanúsítványt telepíteni.
Érdemes megfelelően konfigurálni:
- HTTP → HTTPS átirányítást;
- modern TLS-verziókat;
- biztonságos cookie-beállításokat;
- HSTS-t megfelelő körültekintéssel;
- mixed content problémák megszüntetését.
10. HTTP biztonsági headerek
A böngészőoldali támadások egy része megfelelő HTTP security headerekkel is mérsékelhető.
Fontosabbak például:
Content-Security-Policy;Strict-Transport-Security;X-Content-Type-Options;Referrer-Policy;Permissions-Policy.
Ezek különböző támadási forgatókönyvek ellen nyújthatnak plusz védelmet.
A Content Security Policy különösen erős eszköz, de hibás konfiguráció esetén könnyen megtörheti az oldal működését. Elementor, WooCommerce, analitikai rendszerek, külső fontok, CDN-ek és marketingeszközök használatakor ezért fokozatosan érdemes bevezetni.
11. Web Application Firewall
A WAF, vagyis Web Application Firewall az egyik legfontosabb biztonsági réteg lehet.
A WAF a webes kéréseket vizsgálja, és bizonyos támadási mintákat már a WordPress előtt blokkolhat.
Védelmet nyújthat többek között:
- SQL injection;
- XSS;
- rosszindulatú botok;
- ismert támadási minták;
- brute-force próbálkozások;
- gyanús HTTP-kérések
ellen.
A WAF lehet szerveroldali vagy például CDN-alapú.
A legjobb megoldás gyakran az, amikor a támadó forgalom egy része már a szerver elérése előtt kiszűrésre kerül.
12. Cloudflare és CDN-alapú védelem
Egy CDN nem csak gyorsításra használható.
Megfelelő konfiguráció mellett biztonsági réteget is jelenthet.
A CDN képes lehet:
- DDoS-támadások mérséklésére;
- botforgalom szűrésére;
- rate limitingre;
- WAF-szabályok alkalmazására;
- bizonyos IP-k és országok blokkolására;
- rosszindulatú kérések szűrésére.
A legfontosabb előny, hogy a támadó forgalom egy része nem közvetlenül a WordPress-szervert terheli.
13. Adatbázis biztonsága
A WordPress adatbázisa rengeteg fontos információt tartalmaz.
Ezért fontos:
- erős adatbázis-jelszó;
- megfelelő adatbázis-felhasználói jogosultságok;
- rendszeres biztonsági mentés;
- szükségtelen adatbázis-felhasználók megszüntetése;
- elavult adatok és plugin-maradványok időszakos ellenőrzése.
Fontos megjegyezni, hogy a WordPress adatbázis-prefixének megváltoztatása önmagában nem jelent komoly védelmet. Sokkal fontosabb a valódi hozzáférések és jogosultságok megfelelő kezelése.
14. Fájlfeltöltések védelme
A WordPress médiakezelője miatt a fájlfeltöltés különösen fontos biztonsági terület.
Nem minden fájltípust szükséges engedélyezni.
Különösen óvatosan kell kezelni az olyan formátumokat, amelyek potenciálisan végrehajtható tartalmat hordozhatnak.
Az SVG például hasznos lehet weboldalakon, de nem szabad úgy kezelni, mint egy egyszerű JPG-fájlt. Az SVG XML-alapú formátum, ezért megfelelő tisztítás és ellenőrzés nélkül biztonsági kockázatot jelenthet.
A feltöltési rendszerben ezért fontos:
- csak szükséges MIME-típusok engedélyezése;
- fájltípusok ellenőrzése;
- megfelelő felhasználói jogosultságok;
- feltöltött fájlok megfelelő kezelése;
- szerveroldali végrehajtás megakadályozása az upload könyvtárban, ahol szükséges.
15. Biztonsági mentés – nem opcionális
A biztonsági mentés nem előzi meg a feltörést.
Viszont lehetővé teszi, hogy egy sikeres támadás után visszaállítsuk a weboldalt.
Ezért a backup a biztonsági stratégia egyik legfontosabb része.
Egy professzionális rendszerben célszerű:
- automatikus mentést használni;
- külön menteni az adatbázist;
- menteni a fájlokat;
- több korábbi verziót megtartani;
- a mentéseket elkülönített helyen tárolni;
- időnként tesztelni a visszaállítást.
A „van backup” önmagában nem elég.
A valódi kérdés:
Vissza tudom állítani a weboldalt, ha holnap teljesen kompromittálódik?
Ha erre nincs biztos válasz, akkor nincs megfelelő backup-stratégia.
16. A 3-2-1 mentési stratégia
Komolyabb weboldalaknál érdemes a 3-2-1 szabályt alkalmazni:
- legalább 3 példány az adatokból;
- legalább 2 különböző tárolási hely vagy adathordozó;
- legalább 1 példány fizikailag vagy logikailag elkülönítve.
Ez azért fontos, mert egy támadó nem feltétlenül csak a weboldalt támadja meg.
Ha a backup ugyanazon a szerveren van, mint a weboldal, egy ransomware vagy más támadás azt is törölheti.
17. Adminisztráció és fájlszerkesztés korlátozása
A WordPress adminfelületén bizonyos telepítések lehetővé teszik a pluginok és témák fájljainak közvetlen szerkesztését.
Egy biztonságosabb rendszerben ezt általában érdemes letiltani.
Így egy kompromittált adminisztrátori fiókkal nehezebb közvetlenül PHP-kódot módosítani.
A fejlesztők számára a módosításokat inkább kontrollált fejlesztési vagy deploy folyamaton keresztül célszerű elvégezni.
18. Hibás konfigurációk megszüntetése
A biztonsági problémák jelentős része nem klasszikus WordPress-sebezhetőség.
Gyakran egyszerű konfigurációs hiba okozza.
Például:
- nyitva hagyott tesztoldal;
- régi staging környezet;
- nyilvánosan elérhető backup;
.zipvagy.sqlfájlok a webrootban;- hibás szerverkonfiguráció;
- publikus logfájlok;
- felesleges adminfiókok;
- régi plugin-maradványok.
Ezeket rendszeresen érdemes ellenőrizni.
19. Debug mód és hibák kezelése
Éles weboldalon nem ajánlott a WordPress debug információit nyilvánosan megjeleníteni.
A hibák részletes megjelenítése érzékeny információkat fedhet fel:
- fájlútvonalakat;
- pluginneveket;
- adatbázis-hibákat;
- szerverkonfigurációt;
- belső struktúrát.
Fejlesztési környezetben a debugolás hasznos, de éles környezetben a hibák megjelenítését megfelelően kell konfigurálni.
20. A WordPress admin URL-je önmagában nem biztonsági megoldás
Gyakran felmerül, hogy érdemes-e megváltoztatni a /wp-admin vagy /wp-login.php URL-jét.
Ez bizonyos automatizált támadások mennyiségét csökkentheti, de önmagában nem valódi biztonsági stratégia.
Sokkal fontosabb:
- 2FA;
- rate limiting;
- WAF;
- erős jelszavak;
- megfelelő jogosultságok;
- folyamatos frissítés.
A biztonságot nem érdemes „elrejtésre” építeni.
21. Login és admin hozzáférések naplózása
Komolyabb weboldalaknál hasznos lehet figyelni:
- sikeres bejelentkezéseket;
- sikertelen bejelentkezéseket;
- adminisztrátori műveleteket;
- plugin telepítéseket;
- plugin módosításokat;
- felhasználói jogosultságok változását;
- gyanús fájlmódosításokat.
Ez különösen akkor hasznos, ha több ember dolgozik ugyanazon a weboldalon.
Egy biztonsági rendszernek nem csak blokkolnia kell a támadásokat, hanem lehetőleg jeleznie is kell, ha valami szokatlan történik.
22. Malware-ellenőrzés
A rendszeres malware scanning segíthet felismerni:
- módosított PHP-fájlokat;
- ismeretlen adminfelhasználókat;
- backdoorokat;
- rosszindulatú JavaScriptet;
- fertőzött pluginokat;
- gyanús fájlokat.
Fontos azonban megérteni, hogy egy malware scanner nem helyettesíti a megelőző védelmeket.
Ha a rendszer csak akkor jelez, amikor már megtörtént a feltörés, akkor a védelem egyik fontos része hiányzik.
23. A pluginok számának minimalizálása
A WordPress egyik nagy előnye a bővíthetőség.
Ugyanez azonban biztonsági kockázat is.
Minden plugin:
- új kódot ad az oldalhoz;
- új jogosultságokat kérhet;
- új támadási felületet jelenthet;
- potenciális sérülékenységet hordozhat;
- konfliktusokat okozhat.
Ezért nem az a cél, hogy minél több biztonsági plugint telepítsünk.
Sokkal jobb egy minimalista, jól konfigurált rendszer.
Egy professzionális weboldalon gyakran jobb néhány jól megválasztott komponens, mint tíz különböző plugin, amelyek részben ugyanazokat a funkciókat végzik.
24. A biztonsági plugin sem varázsszer
Gyakori hiba, hogy valaki telepít egy biztonsági plugint, majd úgy tekint a weboldalra, mintha ezzel minden biztonsági probléma megoldódott volna.
Nem így működik.
Egy security plugin hasznos lehet:
- firewall funkciókkal;
- login védelemmel;
- malware scanninggel;
- rate limitinggel;
- audit loggal;
- fájlintegritás-ellenőrzéssel.
De ha közben:
- elavult plugin fut;
- gyenge az admin jelszó;
- nincs backup;
- rosszak a fájljogosultságok;
- nyitva maradnak a szerver hibái;
- fertőzött plugin van telepítve;
akkor egyetlen plugin sem fogja garantálni a biztonságot.
25. WooCommerce esetén még nagyobb a felelősség
Egy WooCommerce-weboldalnál a biztonság kiemelt jelentőségű.
A rendszer többek között kezelhet:
- ügyfélfiókokat;
- rendelési adatokat;
- számlázási adatokat;
- szállítási adatokat;
- e-mail-címeket;
- telefonszámokat;
- rendelési előzményeket.
Ezért különösen fontos:
- adminfiókok 2FA-védelme;
- rendszeres frissítés;
- megbízható fizetési szolgáltató;
- HTTPS;
- megfelelő jogosultságok;
- biztonságos backup;
- WAF;
- rendszeres monitorozás.
A fizetési adatok kezelésekor természetesen az adott fizetési szolgáltató és a vonatkozó jogi, adatvédelmi és biztonsági követelmények is meghatározók.
26. A szerver biztonsága legalább olyan fontos, mint a WordPressé
Nem szabad elfelejteni, hogy a WordPress csak egy alkalmazás a szerveren.
Ha maga a hostingkörnyezet kompromittálódik, akkor a WordPress-védelem jelentős része értelmét veszítheti.
Fontos ezért:
- modern PHP-verzió;
- megfelelő szerverkonfiguráció;
- rendszeresen frissített szerverkomponensek;
- elkülönített hostingfiókok;
- megfelelő SSH/SFTP-védelem;
- erős hostingjelszó;
- 2FA a hostingfióknál;
- megfelelő fájljogosultságok;
- szerveroldali backup.
A hosting szolgáltató biztonsági gyakorlata ezért szintén része a WordPress biztonságának.
27. Ne csak a weboldalt védd
Az egyik leggyakoribb hiba, hogy a weboldalt próbáljuk biztonságossá tenni, miközben a hozzáférést biztosító fiókok gyengék.
Érdemes védeni:
- hostingfiókot;
- domainregisztrátori fiókot;
- e-mail-fiókokat;
- Cloudflare- vagy CDN-fiókot;
- WordPress-fiókokat;
- FTP/SFTP-hozzáférést;
- adatbázis-hozzáférést;
- fejlesztői hozzáféréseket.
Ha például valaki megszerzi a domainregisztrátori fiókot, a weboldal teljes biztonsági konfigurációját megkerülheti.
Ezért a biztonságot teljes infrastruktúraként kell kezelni.
28. Rendszeres biztonsági audit
Egy weboldal biztonsága nem egyszeri projekt.
Az oldal folyamatosan változik:
- új plugin kerül fel;
- plugin frissül;
- új felhasználó érkezik;
- új API-integráció jelenik meg;
- módosul a szerver;
- új funkció kerül a weboldalba.
Ezért időszakosan érdemes ellenőrizni:
- pluginokat;
- témákat;
- felhasználókat;
- jogosultságokat;
- REST API-t;
- XML-RPC-t;
- HTTP headereket;
- fájljogosultságokat;
- backupokat;
- szerverkonfigurációt;
- gyanús fájlokat;
- biztonsági naplókat.
29. A legfontosabb biztonsági alapelvek
Egy professzionális WordPress-weboldalnál a következő alapelveket érdemes követni:
1. Minél kisebb a támadási felület, annál jobb.
Ne legyen engedélyezve olyan funkció, amelyre nincs szükség.
2. Minden hozzáférés legyen a lehető legszűkebb.
Ne legyen mindenki adminisztrátor.
3. Minden komponens legyen naprakész.
A régi plugin az egyik leggyakoribb kockázati tényező.
4. Legyen több védelmi réteg.
WAF + WordPress-védelem + erős hitelesítés + megfelelő szerverkonfiguráció.
5. Legyen valódi backup.
Nem elég, hogy a mentés létezik: visszaállíthatónak is kell lennie.
6. Ne telepítsünk felesleges pluginokat.
Minden plusz komponens új kódot és potenciális kockázatot jelent.
7. Ne csak a WordPressre gondoljunk.
A domain, hosting, e-mail, CDN és fejlesztői hozzáférések ugyanúgy védendők.
Egy professzionális WordPress biztonsági alapkonfiguráció
Egy modern, üzleti célú WordPress-weboldal esetében egy jó kiindulási konfiguráció például a következő:
- HTTPS minden oldalon;
- modern PHP-verzió;
- rendszeresen frissített WordPress core;
- csak aktívan karbantartott pluginok;
- felesleges pluginok és témák eltávolítása;
- erős, egyedi jelszavak;
- 2FA az adminisztrátoroknál;
- login rate limiting;
- WAF;
- DDoS-védelem;
- megfelelő HTTP security headerek;
- szükségtelen XML-RPC funkciók korlátozása;
- szükségtelen REST API-hozzáférések korlátozása;
- megfelelő fájljogosultságok;
wp-config.phpvédelme;- biztonságos fájlfeltöltés;
- rendszeres malware scan;
- admin aktivitás naplózása;
- automatikus backup;
- elkülönített backup-tárolás;
- rendszeres restore-teszt;
- hosting- és domainfiókok 2FA-védelme;
- rendszeres biztonsági audit.
Összegzés
A WordPress biztonsága nem egyetlen plugin, egyetlen .htaccess szabály vagy egyetlen beállítás kérdése.
A valóban biztonságos rendszer többrétegű védelemre épül.
A cél nem az, hogy minden WordPress-funkciót letiltsunk. Ez sok esetben több problémát okozna, mint amennyi előnnyel járna. A cél az, hogy pontosan meghatározzuk, mire van szüksége az adott weboldalnak, majd minden más hozzáférést és funkciót a lehető legkisebb mértékűre korlátozzunk.
Egy jól felépített WordPress-weboldal esetében a biztonság három alapvető pillére:
megelőzés → felismerés → helyreállítás.
A megelőzés csökkenti annak esélyét, hogy a támadás sikeres legyen.
A felismerés lehetővé teszi, hogy egy gyanús eseményre gyorsan reagáljunk.
A helyreállítás pedig biztosítja, hogy még egy sikeres támadás esetén se veszítsük el az egész weboldalt.
Ezért egy professzionális WordPress-rendszernél nem az a kérdés, hogy „feltörhetik-e?”, hanem az, hogy:
mekkora eséllyel sikerül, mennyi kárt tudnak okozni, milyen gyorsan vesszük észre, és mennyi idő alatt tudjuk teljes biztonsággal helyreállítani a rendszert.
Ez az a szemlélet, amely egy egyszerűen működő WordPress-oldalt valóban üzembiztos, professzionálisan védett weboldallá tesz.