Verificarea de securitate a unui site cu SecurityHeaders.com: primul pas simplu înainte de auditul complet

Cum verifici rapid headerele HTTP de securitate și de ce contează pentru orice site sau aplicație web.

Securitatea unui site nu începe întotdeauna cu un audit complex, cu rapoarte tehnice lungi și instrumente greu de înțeles. Uneori, primul pas poate fi mult mai simplu: verificarea headerelor HTTP de securitate.

Un instrument foarte util pentru această verificare este SecurityHeaders.com. Introduci adresa site-ului, alegi dacă vrei să urmărească redirecturile, iar platforma analizează ce headere trimite serverul către browser. La final, primești o notă și o listă de recomandări.

Pentru un site de prezentare, magazin online, portal client, platformă SaaS sau aplicație business, această verificare este un început foarte bun. Nu înlocuiește un audit complet și nu garantează că aplicația este sigură. Totuși, oferă o imagine rapidă asupra unor protecții importante care pot fi activate la nivel de server sau aplicație.

Headerele HTTP de securitate sunt instrucțiuni trimise browserului. Ele reduc riscul unor atacuri precum clickjacking, XSS, încărcare de conținut nesigur sau folosirea necontrolată a unor funcții ale browserului.

Ce sunt headerele HTTP de securitate?

Când un utilizator accesează un site, browserul trimite o cerere către server. Serverul răspunde cu pagina cerută, dar și cu o serie de headere HTTP — metadate despre răspuns.

Headerele de securitate pot controla:

• dacă browserul trebuie să folosească mereu HTTPS;
• dacă pagina poate fi afișată în iframe;
• ce scripturi și resurse externe pot fi încărcate;
• ce informații despre pagina de origine sunt trimise către alte site-uri;
• dacă browserul are voie să ghicească tipul fișierului;
• dacă site-ul poate folosi camera, microfonul sau geolocația;
• cum sunt protejate cookie-urile.

Un site poate funcționa fără aceste headere. Dar asta nu înseamnă că este configurat optim. Lipsa lor nu produce întotdeauna o problemă vizibilă, însă poate lăsa aplicația mai expusă.

De ce SecurityHeaders.com este util

SecurityHeaders.com oferă o verificare rapidă, vizibilă și ușor de înțeles. Introduci domeniul și primești un raport care arată ce headere sunt prezente, ce lipsesc și ce ar trebui îmbunătățit.

Nota (de la A+ în jos) nu este verdict final asupra securității. Un site cu notă bună poate avea vulnerabilități în aplicație. Un site cu notă slabă nu este automat compromis. Dar nota este un semnal bun despre nivelul de hardening la nivel de browser — un punct bun de plecare înaintea unui audit mai amplu.

Strict-Transport-Security (HSTS)

HSTS îi spune browserului că site-ul trebuie accesat doar prin HTTPS. După ce browserul primește acest header, va evita conexiunile nesecurizate către acel domeniu pentru perioada configurată.

Chiar dacă site-ul are certificat SSL, prima cerere poate pleca prin HTTP înainte de redirect. HSTS reduce acest risc. Exemplu:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Totuși, HSTS trebuie activat cu grijă. Dacă există subdomenii care nu funcționează corect pe HTTPS, includeSubDomains poate crea probleme.

Content-Security-Policy (CSP)

CSP permite definirea surselor din care pagina poate încărca scripturi, stiluri, imagini, fonturi, frame-uri, conexiuni API și alte resurse. Este important pentru reducerea impactului atacurilor XSS.

Dacă un atacator injectează un script, o politică CSP bine configurată poate împiedica execuția sau încărcarea din surse neautorizate. O politică prea strictă poate strica site-ul (scripturi legitime, fonturi, analytics). O abordare bună: activare inițială în mod Report-Only, apoi ajustare și activare completă.

X-Frame-Options

Controlează dacă site-ul poate fi afișat într-un iframe — protecție împotriva clickjacking. Valori uzuale: DENY (blocare completă) sau SAMEORIGIN (doar același domeniu). În aplicațiile moderne, protecția poate fi și prin CSP: frame-ancestors.

X-Content-Type-Options

Valoarea uzuală nosniff spune browserului să respecte tipul de conținut declarat de server și să nu încerce să ghicească altceva — reduce riscul ca un fișier încărcat să fie interpretat ca script executabil.

Referrer-Policy

Controlează cât de multă informație despre pagina de origine este trimisă către alte site-uri. Pentru multe site-uri, o alegere echilibrată este:

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy

Controlează funcții ale browserului: cameră, microfon, geolocație, fullscreen, senzori, payment APIs. Dacă site-ul nu le folosește, dezactivează-le explicit:

Permissions-Policy: camera=(), microphone=(), geolocation=()

Cookie-uri: Secure, HttpOnly și SameSite

Un cookie de sesiune ar trebui să aibă, în general, Secure, HttpOnly și SameSite. Secure = doar HTTPS. HttpOnly = inaccesibil din JavaScript (reduce risc XSS). SameSite = limitează trimiterea cross-site (reduce risc CSRF). Configurarea exactă depinde de fluxuri: autentificare, domenii multiple, plăți, integrări.

Ce înseamnă o notă slabă

O notă slabă nu înseamnă automat că site-ul este compromis — înseamnă că lipsesc headere recomandate. Tratează raportul ca listă de îmbunătățiri, nu ca etichetă definitivă. Unele se adaugă rapid; CSP și HSTS necesită testare atentă.

Configurare în Nginx

Exemplu orientativ:

• add_header X-Frame-Options "SAMEORIGIN" always;
• add_header X-Content-Type-Options "nosniff" always;
• add_header Referrer-Policy "strict-origin-when-cross-origin" always;
• add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

CSP trebuie adaptat la scripturi externe, CDN-uri, analytics și API-uri reale ale site-ului.

Configurare în aplicație

Headerele pot fi setate și în Flask, Django, Express (Helmet), Laravel sau Rails — middleware sau extensii dedicate (ex. Flask-Talisman). Multe echipe combină Nginx cu headere în aplicație.

SecurityHeaders.com nu este audit complet

Verificarea headerelor nu înlocuiește testarea pentru SQL injection, XSS în formulare, autentificare slabă, API-uri expuse, rate limiting, upload nesigur, librării vulnerabile, roluri și permisiuni sau backup. Este un quick win important, nu un pentest.

Ce verificări urmează după headere

• SSL/TLS, dependențe, cookie-uri, formulare și login;
• rate limiting, roluri, upload, API, loguri;
• backup/restore, configurare server, staging înainte de producție;
• review de cod pentru zone sensibile.

Verificare periodică și explicare pentru client

Configurațiile se schimbă la update-uri, CDN-uri noi sau subdomenii. Include verificarea în checklist lunar sau audit trimestrial. Pentru clientul non-tehnic: „Headerele sunt instrucțiuni prin care site-ul îi spune browserului ce este permis și ce nu — un strat de protecție invizibil în interfață.”

Concluzie

SecurityHeaders.com este un instrument simplu pentru prima verificare: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Pentru orice site de companie, portal sau aplicație business, verificarea headerelor ar trebui să facă parte din lansare și mentenanță.

Securitatea web se construiește în straturi: HTTPS, headere corecte, cookie-uri protejate, validări, autentificare, testare și monitorizare. Headerele HTTP sunt unul dintre cele mai simple straturi de început — merită configurate corect încă din primele etape.