Security Headers sunt headere HTTP trimise de server către browser prin care pot fi definite reguli suplimentare de securitate pentru website. Acestea pot controla, de exemplu, dacă pagina poate fi încărcată într-un iframe, din ce surse pot fi încărcate scripturile și imaginile sau dacă browserul trebuie să folosească exclusiv HTTPS.
Pe un website găzduit într-un mediu cPanel + LiteSpeed Enterprise, mai multe dintre aceste headere pot fi configurate direct din fișierul .htaccess, fără acces root la server.
Totuși, nu toate Security Headers pot fi copiate într-o configurație universală. Unele, precum
X-Content-Type-Options, X-Frame-Options și Referrer-Policy, sunt relativ simplu de implementat pentru majoritatea website-urilor. Altele, în special Content-Security-Policy, Permissions-Policy și Strict-Transport-Security, trebuie configurate și testate în funcție de website.
O configurație greșită poate bloca JavaScript, CSS, fonturi, imagini, iframe-uri, servicii externe sau chiar subdomenii întregi. Din acest motiv, înainte de orice modificare este important să faci un backup al fișierului .htaccess.
Ce sunt HTTP Security Headers?
Atunci când browserul accesează un website, serverul trimite un răspuns HTTP care conține atât conținutul solicitat, cât și o serie de headere.
Un răspuns simplificat poate arăta astfel:
HTTP/2 200 content-type: text/html; charset=UTF-8 server: LiteSpeed x-content-type-options: nosniff x-frame-options: SAMEORIGIN referrer-policy: strict-origin-when-cross-origin
Unele dintre aceste headere oferă browserului instrucțiuni suplimentare despre modul în care trebuie tratată pagina.
Security Headers pot ajuta la limitarea riscurilor asociate cu:
- clickjacking;
- MIME type sniffing;
- anumite forme de Cross-Site Scripting – XSS;
- încărcarea unor resurse din surse neautorizate;
- expunerea inutilă a informațiilor din Referer;
- utilizarea neautorizată a camerei, microfonului sau geolocației;
- downgrade-ul conexiunilor HTTPS către HTTP.
Security Headers reprezintă însă doar un nivel al securității website-ului. Acestea nu înlocuiesc actualizarea aplicației, parolele sigure, autentificarea cu doi factori, ModSecurity, Imunify360, backup-ul sau certificatul SSL.
Pentru mai multe informații despre protecția la nivel de web server poți consulta și articolul ModSecurity în cPanel și eroarea 403.
Cum verifici Security Headers trimise de website?
Înainte să modifici configurația este recomandat să verifici ce headere sunt deja trimise.
Dacă ai acces la Terminal, Linux, macOS, Windows Terminal sau SSH, poți utiliza:
curl -I https://exemplu.ro
Înlocuiește:
exemplu.ro
cu domeniul pe care dorești să îl verifici.
De exemplu, poți primi:
HTTP/2 200 content-type: text/html; charset=UTF-8 server: LiteSpeed x-content-type-options: nosniff x-frame-options: SAMEORIGIN referrer-policy: strict-origin-when-cross-origin
Pentru a afișa doar headerele de securitate care ne interesează putem folosi:
curl -sI https://exemplu.ro | grep -iE 'content-security|x-frame|x-content-type|referrer-policy|permissions-policy|strict-transport'
Dacă dorești să verifici headerele folosind un request GET real, nu HEAD, poți utiliza:
curl -s -D - -o /dev/null https://exemplu.ro/
Verificarea din browser
Headerele pot fi verificate și fără Terminal.
În Google Chrome, Firefox sau Edge deschide:
Developer Tools → Network
Reîncarcă pagina, selectează documentul principal și verifică:
Headers → Response Headers
Aici vei putea vedea headerele trimise efectiv utilizatorului.
Cum modifici fișierul .htaccess din cPanel?
Pe un cont cPanel, fișierul .htaccess poate fi modificat direct din File Manager.
Autentifică-te în cPanel și accesează:
cPanel → Files → File Manager
Dacă ai nevoie de informații despre accesarea panoului poți consulta tutorialul Cum accesăm contul cPanel?.
Navighează către document root-ul website-ului. Pentru domeniul principal acesta este frecvent:
/public_html
Pentru un domeniu suplimentar poate exista un document root separat.
Dacă fișierul:
.htaccess
nu este vizibil, apasă:
Settings → Show Hidden Files (dotfiles)
și salvează setarea.
Fă un backup înainte de modificare
Înainte să editezi .htaccess este recomandat să îl descarci sau să creezi o copie.
De exemplu:
.htaccess-backup
Dacă apare o eroare după modificare, poți reveni rapid la configurația inițială.
În cazul unui website WordPress, este recomandat să nu introduci regulile personalizate între:
# BEGIN WordPress # END WordPress
WordPress poate rescrie automat conținutul acestei secțiuni. Regulile personalizate pot fi adăugate înainte sau după blocul administrat de WordPress.
Pentru mai multe exemple de utilizare a fișierului .htaccess poți consulta și ghidul despre redirectarea HTTP către HTTPS.
Security Headers pe cPanel și LiteSpeed
Este important să separăm rolurile tehnologiilor utilizate pe server.
Pe infrastructura NameBox sunt utilizate tehnologii precum cPanel, LiteSpeed Enterprise, CloudLinux și Imunify360, însă fiecare are un rol diferit.
LiteSpeed Enterprise este serverul web care procesează request-urile HTTP/HTTPS și generează răspunsurile către browser. LiteSpeed oferă compatibilitate cu configurațiile Apache utilizate în mediile cPanel și permite configurarea Security Headers prin .htaccess.
cPanel oferă interfața prin care utilizatorul își poate administra fișierele și poate modifica .htaccess.
CloudLinux este utilizat pentru izolarea conturilor și administrarea resurselor precum CPU, memorie și I/O. CloudLinux nu este componenta care aplică Security Headers.
AlmaLinux este sistemul de operare pe care poate rula serverul, nu componenta care procesează aceste headere HTTP.
Pentru mai multe informații despre serverul web poți consulta articolul LiteSpeed vs Apache.
A. Security Headers relativ sigure pentru majoritatea website-urilor
Următoarele trei headere reprezintă un punct bun de plecare pentru multe website-uri.
Chiar și în cazul acestora este recomandată testarea după modificare.
X-Content-Type-Options: nosniff
Headerul:
X-Content-Type-Options: nosniff
îi spune browserului să respecte tipul MIME declarat de server prin Content-Type și să nu încerce să interpreteze o resursă ca fiind de alt tip.
Configurația poate fi adăugată în .htaccess astfel:
<IfModule mod_headers.c> Header always set X-Content-Type-Options "nosniff" </IfModule>
De exemplu, un fișier JavaScript trebuie să fie trimis cu un Content-Type corespunzător pentru JavaScript, iar un fișier CSS trebuie să fie livrat ca text/css.
Este important de reținut că nosniff nu repară Content-Type-urile configurate greșit. Dacă serverul livrează o resursă cu un MIME type incorect, aceasta poate fi blocată de browser după activarea headerului.
X-Frame-Options: SAMEORIGIN sau DENY?
X-Frame-Options controlează dacă o pagină poate fi încărcată în interiorul unui frame sau iframe.
Headerul poate limita riscul atacurilor de tip clickjacking, unde un website este încărcat într-un iframe și suprapus cu alte elemente pentru a determina utilizatorul să realizeze acțiuni pe care nu le intenționa.
Două valori importante sunt:
SAMEORIGIN DENY
SAMEORIGIN permite afișarea paginii într-un frame atunci când originea este aceeași.
Exemplu:
Header always set X-Frame-Options "SAMEORIGIN"
DENY nu permite încărcarea paginii într-un frame, indiferent de origine.
Header always set X-Frame-Options "DENY"
Pentru majoritatea website-urilor obișnuite, SAMEORIGIN este mai flexibil.
Dacă website-ul nu trebuie niciodată afișat într-un iframe, poate fi analizată utilizarea DENY.
Dacă aplicația trebuie integrată în iframe-uri de pe alte domenii, X-Frame-Options poate deveni prea restrictiv. În configurațiile moderne poate fi utilizată și directiva CSP:
frame-ancestors
care permite politici mai precise.
Referrer-Policy: strict-origin-when-cross-origin
Atunci când utilizatorul accesează un link către altă pagină, browserul poate trimite informații despre pagina de pe care a venit prin headerul:
Referer
Referrer-Policy permite controlarea cantității de informații transmise.
O valoare echilibrată pentru multe website-uri este:
strict-origin-when-cross-origin
Configurația:
Header always set Referrer-Policy "strict-origin-when-cross-origin"
permite transmiterea mai multor informații pentru navigarea în cadrul aceleiași origini, dar limitează informațiile transmise către alte origini.
La trecerea de la HTTPS către o destinație HTTP mai puțin sigură, informația Referer nu este transmisă.
Exemplu .htaccess pentru cele trei headere de bază
Pentru multe website-uri, un punct de pornire poate fi:
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
Aceste headere sunt relativ ușor de implementat, dar configurația trebuie verificată după salvarea fișierului.
Nu adăuga automat și următoarele headere în același bloc fără să înțelegi efectul lor.
B. Security Headers care trebuie adaptate website-ului
Content-Security-Policy, Permissions-Policy și HSTS pot oferi protecții suplimentare importante, dar trebuie configurate în funcție de modul în care funcționează website-ul.
O regulă copiată de pe alt site poate produce probleme majore.
Content-Security-Policy – CSP
Content-Security-Policy este unul dintre cele mai puternice Security Headers disponibile browserelor moderne.
CSP permite administratorului să definească sursele din care pagina are voie să încarce diferite tipuri de conținut.
De exemplu, o politică poate spune:
JavaScript → doar de pe domeniul propriu CSS → domeniul propriu + Google Fonts Imagini → domeniul propriu + CDN iframe → doar YouTube API → doar anumite endpoint-uri
Browserul va putea bloca resursele care nu respectă politica.
Ce poate limita Content Security Policy?
O configurație CSP bine realizată poate reduce impactul unor vulnerabilități și atacuri precum:
- Cross-Site Scripting – XSS;
- injectarea de scripturi;
- încărcarea resurselor din surse neautorizate;
- anumite forme de clickjacking;
- executarea unor elemente injectate într-o pagină compromisă.
CSP nu repară însă vulnerabilitatea aplicației. Aceasta reprezintă un strat suplimentar de protecție aplicat de browser.
Directive importante CSP
O politică CSP este alcătuită din mai multe directive.
default-src
Definește politica implicită pentru tipurile de resurse care nu au o directivă mai specifică.
default-src 'self'
‘self’ reprezintă aceeași origine ca website-ul curent.
script-src
Controlează sursele din care poate fi încărcat și executat JavaScript.
script-src 'self'
O astfel de regulă este foarte restrictivă și poate bloca Google Analytics, Google Tag Manager, reCAPTCHA, scripturile procesatorilor de plăți sau JavaScript inline.
style-src
Controlează sursele CSS.
style-src 'self'
Poate afecta Google Fonts, stylesheet-uri externe și stiluri inline generate de WordPress, teme sau page builders.
img-src
Controlează sursele din care pot fi încărcate imaginile.
De exemplu:
img-src 'self' data: https:
Acest exemplu permite imagini din propria origine, data URI și surse HTTPS, dar trebuie analizat în funcție de website.
font-src
Controlează sursele fonturilor.
font-src 'self'
Dacă website-ul utilizează Google Fonts sau un CDN extern, politica trebuie adaptată.
connect-src
Controlează destinațiile către care pot fi realizate anumite conexiuni din browser, de exemplu prin Fetch, XMLHttpRequest sau WebSocket.
Este important pentru:
- API-uri;
- Google Analytics;
- servicii externe;
- aplicații JavaScript;
- servicii de monitorizare.
frame-src
Controlează sursele care pot fi încărcate într-un iframe.
Este relevant pentru servicii precum:
- YouTube;
- Google Maps;
- reCAPTCHA;
- procesatori de plăți;
- platforme video;
- widget-uri externe.
frame-ancestors
Controlează ce site-uri au voie să încarce pagina ta într-un iframe.
De exemplu:
frame-ancestors 'self'
are un rol similar cu X-Frame-Options SAMEORIGIN, dar permite configurații CSP mai flexibile.
form-action
Poate limita destinațiile către care formularele din pagină au voie să trimită date.
form-action 'self'
Acest lucru trebuie verificat dacă website-ul utilizează formulare care trimit utilizatorul către procesatori de plăți sau servicii externe.
De ce nu există o configurație CSP universală?
Fiecare website încarcă resurse diferite.
Un site simplu poate utiliza exclusiv fișiere locale, în timp ce un magazin online sau un website WordPress poate comunica cu zeci de servicii externe.
Printre serviciile care trebuie analizate se numără:
- Google Fonts;
- Google Analytics;
- Google Tag Manager;
- YouTube;
- Google Maps;
- Google reCAPTCHA;
- Cloudflare sau alte CDN-uri;
- Meta Pixel;
- chat-uri externe;
- procesatori de plăți;
- API-uri;
- fonturi și scripturi furnizate de teme sau pluginuri.
În WordPress, situația poate deveni și mai complexă deoarece o temă, un plugin sau un page builder poate adăuga JavaScript și CSS inline.
Pentru informații despre administrarea WordPress poți consulta articolul Cum instalez WordPress direct din cPanel?.
Ce se întâmplă dacă CSP este configurat greșit?
Să presupunem că introduci:
Content-Security-Policy: default-src 'self'
Această regulă poate părea sigură, însă un website care folosește servicii externe poate începe imediat să aibă probleme.
Pot fi blocate:
- scripturile Google Analytics;
- Google Tag Manager;
- Google Fonts;
- imagini de pe CDN;
- iframe-uri YouTube;
- reCAPTCHA;
- widget-uri externe;
- checkout-uri sau componente ale procesatorilor de plăți;
- request-uri API.
Website-ul poate continua să afișeze pagina HTML, dar anumite funcții pot să nu mai funcționeze.
Nu rezolva automat problemele CSP adăugând * sau ‘unsafe-inline’ peste tot. Aceste modificări pot reduce semnificativ protecția pe care CSP ar trebui să o ofere.
Testează CSP cu Content-Security-Policy-Report-Only
Înainte să aplici o politică restrictivă este recomandat să o testezi.
Pentru aceasta există:
Content-Security-Policy-Report-Only
În acest mod browserul poate identifica încălcările politicii fără să blocheze efectiv resursele.
De exemplu, pentru testare:
<IfModule mod_headers.c> Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self' https:; connect-src 'self'; frame-src 'self'" </IfModule>
Acesta este doar un exemplu pentru testare și nu o politică recomandată universal.
După activare, deschide:
Developer Tools → Console
și navighează prin website.
Browserul poate afișa resursele care ar fi fost blocate dacă politica ar fi fost aplicată efectiv.
Testează în special:
- homepage-ul;
- formularele;
- wp-admin;
- login-ul;
- checkout-ul;
- plățile;
- video-urile;
- hărțile;
- reCAPTCHA;
- funcțiile JavaScript;
- pagini care comunică cu API-uri.
Dacă dorești centralizarea automată a rapoartelor CSP, trebuie configurat și un endpoint capabil să primească rapoartele împreună cu mecanismul Reporting API. Nu este suficient să introduci o adresă aleatorie în .htaccess.
Permissions-Policy
Permissions-Policy permite controlarea accesului paginii și al conținutului încorporat la anumite funcții ale browserului sau dispozitivului.
Printre acestea se numără:
- camera;
- microfonul;
- geolocația;
- anumite funcții asociate dispozitivului.
Dacă website-ul nu are nevoie de cameră, microfon sau geolocație, un exemplu este:
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Această configurație dezactivează funcțiile respective.
Nu trebuie însă aplicată automat.
De exemplu, poate afecta:
- un website care permite realizarea unei fotografii cu camera;
- o platformă de videoconferință;
- o aplicație care utilizează microfonul;
- un magazin care detectează locația utilizatorului.
În plus, suportul pentru anumite directive Permissions-Policy poate varia între browsere, motiv pentru care configurația trebuie verificată înainte de producție.
Strict-Transport-Security – HSTS
Strict-Transport-Security, cunoscut și ca HSTS, îi spune browserului că website-ul trebuie accesat exclusiv prin HTTPS.
După ce browserul primește politica HSTS printr-o conexiune HTTPS, viitoarele încercări de acces prin HTTP sunt convertite automat către HTTPS de browser.
Un exemplu este:
Strict-Transport-Security: max-age=31536000
Valoarea:
31536000
reprezintă un an în secunde.
Când poate fi activat HSTS?
HSTS trebuie analizat doar după ce website-ul funcționează complet prin HTTPS.
Înainte de activare verifică:
- certificatul SSL este valid;
- HTTP redirecționează către HTTPS;
- toate paginile funcționează prin HTTPS;
- nu există probleme Mixed Content importante;
- serviciile website-ului nu depind de acces HTTP.
Pentru informații despre HTTPS poți consulta pagina de certificate SSL NameBox și articolul despre redirect HTTP către HTTPS.
Testează HSTS cu un max-age redus
Dacă dorești să testezi HSTS, poți începe cu o perioadă mai redusă înainte de a configura o valoare de un an.
De exemplu:
<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=86400" </IfModule>
Această valoare reprezintă o zi.
După ce ai confirmat că HTTPS funcționează corect pentru website, politica poate fi reevaluată.
Pentru o perioadă de un an:
Header always set Strict-Transport-Security "max-age=31536000"
HSTS este luat în considerare de browser numai atunci când este primit printr-o conexiune HTTPS.
Ce face includeSubDomains?
Poți întâlni și configurația:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
includeSubDomains extinde politica HSTS către subdomenii.
De exemplu, pentru:
exemplu.ro
politica poate afecta și:
shop.exemplu.ro mail.exemplu.ro client.exemplu.ro api.exemplu.ro
Nu activa includeSubDomains dacă nu ești sigur că toate subdomeniile sunt și vor rămâne disponibile prin HTTPS.
Un subdomeniu care funcționează doar prin HTTP poate deveni inaccesibil în browser după aplicarea politicii.
Ce este HSTS preload?
Poți întâlni configurații precum:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Preload permite introducerea domeniului într-o listă HSTS distribuită direct în browsere.
Astfel, browserul poate ști că domeniul necesită HTTPS chiar înainte de prima conexiune.
Nu recomandăm activarea preload doar pentru a obține un scor mai bun într-un instrument de testare Security Headers.
Înainte de preload trebuie să fii sigur că:
- domeniul funcționează exclusiv prin HTTPS;
- toate subdomeniile funcționează prin HTTPS;
- includeSubDomains poate fi activat în siguranță;
- înțelegi consecințele pe termen lung;
- infrastructura viitoare va păstra HTTPS pentru toate hostname-urile afectate.
Eliminarea unui domeniu dintr-o listă preload nu are efect instantaneu în toate browserele. De aceea, preload trebuie tratat ca o decizie importantă de infrastructură, nu ca o simplă linie adăugată în .htaccess.
Configurație .htaccess recomandată ca punct de pornire
Nu recomandăm adăugarea tuturor Security Headers într-un singur snippet universal.
Împărțim configurația în două categorii.
A. Headere relativ sigure pentru majoritatea website-urilor
Acesta poate reprezenta un punct de pornire:
<IfModule mod_headers.c>
# Previne MIME type sniffing
Header always set X-Content-Type-Options "nosniff"
# Limitează afișarea website-ului în iframe-uri
Header always set X-Frame-Options "SAMEORIGIN"
# Limitează informațiile Referer transmise către alte origini
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
După adăugare, salvează .htaccess și testează website-ul.
B. Headere care trebuie configurate și testate separat
Următoarele exemple nu trebuie copiate automat într-un website live.
Content-Security-Policy – testare:
<IfModule mod_headers.c> Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; font-src 'self' https:; connect-src 'self'; frame-src 'self'" </IfModule>
După identificarea tuturor resurselor necesare, politica trebuie adaptată website-ului înainte de transformarea ei în:
Content-Security-Policy
Permissions-Policy:
<IfModule mod_headers.c> Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()" </IfModule>
Folosește această configurație numai dacă website-ul nu are nevoie de funcțiile respective.
HSTS pentru testare:
<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=86400" </IfModule>
După verificarea completă a HTTPS poate fi analizată o perioadă mai mare.
Nu adăuga includeSubDomains sau preload înainte să verifici toate subdomeniile.
Cum verifici Security Headers după modificare?
După salvarea fișierului .htaccess verifică website-ul:
curl -I https://exemplu.ro
Ar trebui să vezi, în funcție de configurația aplicată:
x-content-type-options: nosniff x-frame-options: SAMEORIGIN referrer-policy: strict-origin-when-cross-origin
Dacă ai configurat și alte politici:
content-security-policy-report-only: ... permissions-policy: ... strict-transport-security: ...
Pentru filtrare rapidă:
curl -sI https://exemplu.ro | grep -iE 'content-security|x-frame|x-content-type|referrer-policy|permissions-policy|strict-transport'
Testează mai mult decât homepage-ul
Faptul că homepage-ul se afișează corect nu înseamnă că întregul website funcționează după modificarea Security Headers.
Testează și:
- paginile interne;
- formularele de contact;
- login-ul;
- wp-admin;
- Google Maps;
- video-urile YouTube;
- reCAPTCHA;
- Google Analytics;
- Tag Manager;
- chat-urile externe;
- checkout-ul unui magazin online;
- procesarea plăților;
- API-urile și AJAX;
- fonturile și imaginile externe.
Verifică Browser Console după activarea CSP
Pentru Content Security Policy, unul dintre cele mai utile instrumente este:
Developer Tools → Console
Dacă o resursă este refuzată de CSP, browserul poate afișa un mesaj asemănător cu:
Refused to load the script because it violates the following Content Security Policy directive...
Mesajul indică de regulă tipul resursei și directiva care a provocat problema.
Nu adăuga domeniul respectiv automat în whitelist. Verifică mai întâi dacă resursa este legitimă și dacă website-ul are într-adevăr nevoie de ea.
Ce faci dacă website-ul nu mai funcționează după modificarea .htaccess?
Dacă website-ul afișează o eroare imediat după modificare, primul pas este revenirea la configurația anterioară.
Înlocuiește fișierul cu backup-ul realizat înainte:
.htaccess-backup
sau elimină doar regulile nou adăugate.
Dacă apare o eroare 500, este posibil să existe o problemă de sintaxă în .htaccess.
Dacă pagina se deschide, dar anumite componente nu funcționează, verifică:
- Browser Console;
- Network;
- Content Security Policy;
- iframe-urile;
- fonturile;
- scripturile externe.
Nu confunda Security Headers cu permisiunile fișierelor
Security Headers și permisiunile Linux rezolvă probleme complet diferite.
Headerele HTTP controlează comportamentul browserului, în timp ce permisiunile stabilesc cine poate citi, scrie sau executa fișiere pe server.
Pentru mai multe informații poți consulta ghidul Permisiuni fișiere în cPanel: 644, 755 și 777.
Security Headers nu înlocuiesc securitatea serverului
Security Headers pot limita anumite riscuri la nivelul browserului, însă nu pot proteja singure un website compromis.
De exemplu, CSP nu înlocuiește:
- actualizarea WordPress;
- actualizarea pluginurilor și temelor;
- ModSecurity;
- Imunify360;
- parolele puternice;
- autentificarea 2FA;
- backup-ul;
- protecția accesului SSH sau cPanel.
Pe infrastructura NameBox, LiteSpeed Enterprise este utilizat ca server web, CloudLinux pentru izolarea și administrarea resurselor conturilor, iar Imunify360 și ModSecurity oferă niveluri suplimentare de securitate pentru aplicațiile web.
Security Headers completează aceste tehnologii prin reguli aplicate de browser după ce răspunsul HTTP a fost primit.
Ai grijă la headerele configurate în mai multe locuri
Un website poate avea Security Headers definite din mai multe surse:
- .htaccess;
- configurația web serverului;
- aplicația PHP;
- un plugin WordPress;
- un CDN sau reverse proxy;
- o platformă externă precum Cloudflare.
Dacă același header este configurat în mai multe locuri, pot apărea valori duplicate sau politici care nu corespund intenției administratorului.
De aceea, verificarea trebuie realizată întotdeauna pe răspunsul public final:
curl -I https://exemplu.ro
și nu doar prin examinarea fișierului .htaccess.
O configurație mai strictă nu este automat una mai bună
Scopul Security Headers nu este să activezi cât mai multe reguli doar pentru a obține un scor maxim într-un scanner online.
O politică trebuie să protejeze website-ul fără să îi afecteze funcționalitatea.
Pentru majoritatea website-urilor poți începe cu:
X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Referrer-Policy: strict-origin-when-cross-origin
Apoi analizează separat dacă proiectul permite utilizarea:
- Content-Security-Policy;
- Permissions-Policy;
- Strict-Transport-Security.
Pentru CSP, începe cu Content-Security-Policy-Report-Only, identifică toate resursele utilizate și aplică politica numai după testare.
Pentru HSTS, verifică mai întâi că HTTPS funcționează corect pe întregul website și tratează includeSubDomains și mai ales preload cu atenție.
Dacă utilizezi serviciile de găzduire web NameBox, configurațiile .htaccess sunt procesate în mediul cPanel + LiteSpeed, iar Security Headers pot fi aplicate la nivelul website-ului fără modificarea configurației globale a serverului.