Headere de securitate HTTP în WordPress: CSP, HSTS și X-Frame-Options

Îți poți proteja WordPress-ul cu pluginuri, parole tari și backup-uri, dar dacă browserul vizitatorilor nu primește instrucțiuni clare despre cum să trateze site-ul tău, lași o ușă întredeschisă. Exact aici intervin headerele de securitate WordPress: mici directive pe care serverul le trimite odată cu fiecare pagină și care spun browserului ce are voie și ce nu are voie să facă. Sunt invizibile pentru utilizator, dar fac diferența dintre un site rezistent și unul ușor de exploatat.

Ce sunt headerele de securitate WordPress și de ce contează

Un header HTTP este o linie de metadate pe care serverul o trimite înaintea conținutului propriu-zis. Headerele de securitate sunt un subset care instruiește browserul să aplice reguli defensive: să forțeze HTTPS, să blocheze scripturile neautorizate sau să refuze încărcarea site-ului într-un iframe străin.

Avantajul lor e că acționează la nivelul browserului, adică înainte ca un atac să apuce să ruleze cod pe pagina ta. Le poți vedea ca pe niște straturi succesive de apărare, fiecare acoperind un tip diferit de risc. Vestea bună: nu ai nevoie de un plugin greu pentru ele, ci doar de câteva linii de configurare puse la locul potrivit.

HSTS: forțează conexiunea criptată

HSTS (HTTP Strict Transport Security) îi spune browserului să comunice cu site-ul tău exclusiv prin HTTPS, chiar dacă cineva tastează adresa cu „http://”. Odată memorată regula, browserul nu mai face nici măcar prima cerere nesecurizată, eliminând fereastra în care un atacator ar putea intercepta traficul.

O valoare tipică arată așa: Strict-Transport-Security: max-age=31536000. Pentru WordPress, recomandarea este să începi fără preload și fără includeSubDomains, ca să nu blochezi din greșeală subdomenii care încă rulează pe HTTP. Le adaugi mai târziu, când ești sigur că întreg ecosistemul e trecut pe HTTPS.

Atenție la certificatul SSL

HSTS presupune un certificat SSL valid și reînnoit la timp. Dacă certificatul expiră, vizitatorii nu vor mai putea accesa deloc site-ul până îl repari, pentru că browserul refuză categoric conexiunea nesecurizată. Monitorizează-i expirarea și folosește reînnoirea automată.

CSP: cel mai puternic header, dar și cel mai sensibil

Content Security Policy (CSP) definește exact ce surse de scripturi, stiluri, imagini sau fonturi are voie să încarce pagina. Este cea mai eficientă barieră împotriva atacurilor de tip XSS, pentru că un script injectat dintr-o sursă neautorizată pur și simplu nu rulează.

Problema e că un CSP prea strict poate bloca resurse legitime: Google Fonts, un script de analytics sau chiar stiluri inline din temă. De aceea regula de aur este să pornești în modul Content-Security-Policy-Report-Only, care doar raportează încălcările fără să blocheze nimic, iar apoi să treci la varianta care aplică efectiv politica. Poți citi cum funcționează în detaliu în documentația web.dev despre CSP.

Pentru scripturile inline chiar necesare — cum e cel care previne flash-ul alb la trecerea pe tema închisă — folosește un hash sau un nonce, nu unsafe-inline, care ar anula jumătate din beneficii.

X-Frame-Options: scut împotriva clickjacking-ului

Clickjacking-ul înseamnă că cineva îți încarcă site-ul într-un iframe transparent, suprapus peste altă pagină, ca să te păcălească să dai click pe butoane fără să-ți dai seama. Headerul X-Frame-Options: SAMEORIGIN interzice încărcarea paginilor tale în iframe-uri de pe alte domenii și oprește din start acest tip de atac.

Celelalte headere pe care merită să le adaugi

Pe lângă cele trei mari, câteva headere scurte închid riscuri frecvente:

• X-Content-Type-Options: nosniff — oprește browserul din a „ghici” tipul unui fișier și a-l executa greșit.
• Referrer-Policy: strict-origin-when-cross-origin — limitează informația despre adresa ta trimisă către site-uri externe.
• Permissions-Policy — dezactivează API-uri sensibile (cameră, microfon, geolocație) de care site-ul nu are nevoie.

Poți verifica scorul întregii configurații cu un instrument gratuit precum securityheaders.com, care îți dă o notă de la F la A+ și îți arată exact ce lipsește.

Cum le adaugi corect în WordPress

Ai două locuri principale unde le poți seta: la nivel de server (fișierul .htaccess pe Apache sau LiteSpeed, ori configul Nginx) sau din PHP, prin hook-ul send_headers al WordPress. Varianta la nivel de server e de preferat, pentru că se aplică tuturor răspunsurilor, inclusiv fișierelor statice.

Indiferent de metodă, testează după fiecare modificare: deschide consola browserului, verifică tab-ul Network și confirmă că nu ai stricat stiluri sau funcționalități. Un CSP configurat greșit poate „albi” jumătate de site fără niciun mesaj de eroare vizibil. Dacă vrei o abordare completă, cu toate straturile puse la punct și testate, vezi serviciul nostru de securitate WordPress sau cere un audit gratuit în care îți verificăm exact ce headere lipsesc de pe site.

Headerele de securitate nu înlocuiesc un firewall sau backup-urile, dar sunt printre cele mai ieftine și mai eficiente măsuri pe care le poți lua: câteva linii de configurare care ridică imediat rezistența site-ului. Adaugă-le treptat, testează după fiecare pas și site-ul tău va deveni vizibil mai greu de atacat.