Sari la conținut
Toate articolele
11 iulie 2026·3 min citire

Hardening WordPress dincolo de plugin-uri: 12 setări la server și în wp-config

Măsuri reale de securitate WordPress la nivel de server și wp-config — permisiuni, chei, headers — nu doar un plugin instalat și uitat.

Plugin-urile de securitate ajută, dar au o limită clară: rulează în interiorul WordPress, adică abia după ce cererea a ajuns deja la PHP. Cele mai solide măsuri stau mai jos — la nivelul serverului web și în wp-config.php, acolo unde un plugin nu ajunge. Sunt setări pe care le faci o dată, rămân active în tăcere și nu încarcă site-ul.

Mai jos ai 12 lucruri concrete pe care le poți verifica sau cere hostingului. Nu înlocuiesc bunul-simț (parole bune, updateuri la zi), dar ridică serios ștacheta pentru cineva care încearcă să intre. Și un avertisment onest: dacă cineva îți promite un site „imposibil de spart", fugi — securitatea e straturi, nu o bifă.

Permisiuni de fișiere care nu lasă uși deschise

Permisiunile greșite sunt printre cele mai comune probleme. Regula simplă:

  • directoare: 755
  • fișiere: 644
  • wp-config.php: 600 (sau 640), citit doar de utilizatorul serverului

Niciodată 777 pe ceva — înseamnă „oricine poate scrie". Verifică și proprietarul fișierelor: totul ar trebui deținut de userul sub care rulează PHP, nu de root. Un semn bun e că nici WordPress nu ar trebui să poată edita fișierele de temă direct — dacă poate, poate și un atacator care compromite un cont. wp-config.php merită tratat separat, pentru că ține cheile bazei de date.

wp-config.php — de aici se dă tonul

Fișierul acesta e inima instalării. Câteva linii care contează:

  • Chei și saluri (SALT) unice, generate din serviciul oficial WordPress — invalidează sesiunile furate.
  • define('DISALLOW_FILE_EDIT', true); — scoate editorul de teme/plugin-uri din admin, ca nimeni să nu injecteze cod dintr-un cont compromis.
  • define('FORCE_SSL_ADMIN', true); — forțează HTTPS în zona de administrare.
  • define('WP_DEBUG', false); și WP_DEBUG_DISPLAY dezactivat în producție, ca erorile să nu expună căi de server.

Opțional, poți muta wp-config.php un nivel mai sus de rădăcina publică și schimba prefixul tabelelor de la wp_ la ceva propriu. Nu sunt gloanțe de argint, dar reduc suprafața.

Reguli la serverul web (Apache / Nginx)

Aici blochezi accesul înainte ca PHP să pornească.

  • Interzice accesul direct la fișiere sensibile: wp-config.php, .htaccess, readme.html, xmlrpc.php (dacă nu folosești XML-RPC).
  • Dezactivează listarea directoarelor (Options -Indexes pe Apache), ca nimeni să nu răsfoiască folderele.
  • Cel mai important: oprește execuția PHP în wp-content/uploads. Dacă un atacator reușește să urce un fișier .php deghizat, fără execuție acolo devine inofensiv.

Pe Nginx sunt blocuri location, pe Apache reguli în .htaccess sau în config. Dacă ești pe hosting shared, cere-le celor de la suport să aplice aceste reguli — e o solicitare normală.

Security headers — răspunsuri care spun browserului regulile

Anteturile HTTP nu opresc un hack de server, dar închid multe atacuri din browser (clickjacking, sniffing de conținut, downgrade la HTTP). Merită setate:

  • Strict-Transport-Security (HSTS) — obligă browserul să folosească doar HTTPS.
  • X-Content-Type-Options: nosniff — oprește ghicitul tipului de fișier.
  • X-Frame-Options: SAMEORIGIN (sau CSP frame-ancestors) — anti-clickjacking.
  • Referrer-Policy și Permissions-Policy — limitează ce se scurge și ce API-uri de browser sunt permise.

Le poți pune la nivel de server sau prin platformă (reguli de headers). Poți verifica rezultatul cu orice scanner public de headers, gratuit.

Baza de date, conturi și mentenanță

Ultimul strat ține de igienă:

  • Utilizatorul de bază de date să aibă doar drepturile necesare pe baza lui — nu un cont root global.
  • Fără username „admin" și cu parole lungi, unice; ideal, autentificare în doi pași pe conturile de administrare.
  • Ține PHP și WordPress la o versiune suportată — multe breșe vin din software vechi, nu din atacuri sofisticate.
  • Backup automat, testat, stocat în altă parte decât serverul.

Așa arată o instalare tratată serios la MPO Web Studio: livrăm site-uri deja hardenate, remote, în toată țara, cu setările astea făcute din start. Dacă vrei o părere pe site-ul tău actual, scrie-ne pe WhatsApp — îți spunem cinstit ce merită schimbat.

Întrebări frecvente

Nu e suficient un plugin de securitate ca Wordfence?+

Ajută, dar rulează în interiorul WordPress, deci după ce cererea a ajuns la PHP. Setările de la server și din wp-config acționează mai devreme și mai adânc. Ideal le folosești împreună, nu una în locul celeilalte.

Pot face aceste setări pe hosting shared?+

Pe wp-config.php da, ai acces mereu. Pentru reguli de server și headers, unele le poți pune în .htaccess; altele le ceri de la suportul hostingului — e o solicitare obișnuită și ar trebui să te ajute.

Schimbarea prefixului tabelelor sau ascunderea wp-login chiar contează?+

Sunt măsuri de „reducere a zgomotului", nu protecții reale. Ajută marginal, dar nu te baza pe ele. Permisiunile corecte, HTTPS forțat, updateurile și backupul contează mult mai mult.

XML-RPC — îl dezactivez sau nu?+

Dacă nu folosești aplicația mobilă WordPress, Jetpack sau publicare la distanță, îl poți bloca — e o țintă frecventă pentru atacuri brute-force. Verifică întâi că nimic din site nu depinde de el.

Cât de des trebuie refăcute aceste setări?+

Odată făcute, rămân. Dar verifică permisiunile după migrări, ține updateurile la zi și testează backupul periodic. Securitatea e întreținere, nu un proiect încheiat.

Ghid gratuit

7 greșeli care îți alungă clienții de pe site

Lasă-ți emailul și primești ghidul pe loc, aici. Fără spam.

Prin trimitere, ești de acord cu Politica de confidențialitate.
Gratuit · fără obligații

Vrei să vezi cum ar arăta site-ul firmei tale?

Scrie-ne pe WhatsApp și îți pregătim GRATUIT un site demonstrativ, cu numele firmei tale. Îl vezi întâi — decizi după.

Cere un site demonstrativ gratuitÎți răspundem pe WhatsApp în câteva minute