gr.AI
Întrebare explicată · gr.AI

Contează headerele de securitate pentru vizibilitatea în AI?

de Cătălin Popa · actualizat 2026-09-01

Nu. Nimeni nu a demonstrat vreodată că un motor AI te preferă pentru că ai politicile de securitate configurate corect, iar noi nu o să pretindem că sunt factor de clasare.

Sunt altceva. Un semnal despre cine ține site-ul și cât de serios, verificabil de oricine în două secunde, fără să ceară voie nimănui. Iar în cazul unei agenții care vinde audituri tehnice, e primul lucru pe care un client informat îl testează.

Ce fac de fapt, pe scurt

  1. 01

    Content-Security-Policy

    Spune browserului de unde are voie să încarce scripturi, stiluri, imagini și fonturi. Tot ce nu e pe listă nu rulează.

    Fără el
    Orice script strecurat în pagină, printr-un plugin compromis sau printr-un câmp needucat, rulează cu drepturile tale depline.

  2. 02

    Strict-Transport-Security

    Obligă browserul să folosească HTTPS pentru domeniul tău, chiar dacă cineva tastează adresa fără s.

    Fără el
    Prima cerere pleacă pe HTTP și poate fi interceptată înainte de redirecționare.

  3. 03

    X-Frame-Options

    Împiedică alt site să încarce paginile tale într-un cadru invizibil peste care își pune propriile butoane.

    Fără el
    Cineva îți poate suprapune interfața peste a lui, iar clicurile utilizatorului ajung unde vrea el.

  4. 04

    X-Content-Type-Options

    Oprește browserul din a ghici tipul unui fișier. Dacă serverul zice că e imagine, rămâne imagine.

    Fără el
    Un fișier încărcat de utilizator, declarat imagine, poate fi reinterpretat ca script.

  5. 05

    Referrer-Policy

    Limitează cât din adresa paginii curente pleacă mai departe când utilizatorul dă click spre alt site.

    Fără el
    Adrese interne, uneori cu identificatori în ele, ajung în jurnalele altcuiva.

  6. 06

    Permissions-Policy

    Închide explicit ce nu folosești: cameră, microfon, geolocație, plăți, USB.

    Fără el
    Un script terț poate cere permisiuni pe care site-ul tău nu are niciun motiv să le atingă.

Muzeul CFR, pornit de la „nu se încarcă nimic din exterior”

Cea mai strictă politică din portofoliu, și cea mai simplu de explicat. Începe cu default-src 'none', ceea ce înseamnă că, implicit, nimic nu are voie să se încarce. Apoi se deschide punctual doar ce e nevoie.

default-src 'none';
script-src 'self'; style-src 'self'; img-src 'self';
font-src 'self'; media-src 'self'; connect-src 'self';
frame-src https://www.openstreetmap.org;
base-uri 'none'; form-action 'none'; frame-ancestors 'self';
upgrade-insecure-requests

O singură excepție, pentru harta OpenStreetMap de pe pagina de contact. În rest, scripturi, stiluri, imagini și fonturi vin numai de pe domeniul propriu. form-action 'none' înseamnă că nicio pagină nu poate trimite un formular nicăieri, ceea ce e corect pentru un site care nu are formulare.

Coral Baby, un singur script permis prin amprentă

La fel de strâns, cu o diferență care merită explicată. Site-ul are nevoie de un script inline, iar în loc să deschidă poarta pentru toate scripturile inline, politica permite exact unul, identificat prin amprenta lui criptografică.

script-src 'self' 'sha256-tHd4qJ0R/vQfI0CbRTiL3XGSi+Tun7VhOcDbx08aLKA='

Se schimbă un caracter în script, amprenta nu mai corespunde și scriptul nu mai rulează. Costul e că orice modificare cere regenerarea amprentei. Câștigul e că nu există nicio portiță prin care un script străin să se execute.

Ce am reparat pe propriul nostru site

Până pe 27 august 2026, gr-ai.ro avea un singur header de securitate, iar acela incomplet. Le ceream clienților ceva ce noi nu aveam.

HeaderÎnainteAcum
Content-Security-Policylipseapolitică completă
X-Content-Type-Optionslipseanosniff
X-Frame-OptionslipseaSAMEORIGIN
Referrer-Policylipseastrict-origin-when-cross-origin
Cross-Origin-Opener-Policylipseasame-origin
Permissions-Policylipseacameră, microfon, geolocație, plăți, USB
Strict-Transport-Securitydoar max-ageincludeSubDomains, preload
Access-Control-Allow-Origin* pe tot site-uldoar pe /badge/

Ultimul rând e cel care ne deranja cel mai tare. Access-Control-Allow-Origin: * venea de la platformă, apărea pe fiecare răspuns, inclusiv pe robots.txt, și noi nu-l pusesem nicăieri în cod. Nu era o gaură de securitate, pentru că lipsea Access-Control-Allow-Credentials, deci nu permitea citiri autentificate. Era doar neglijență vizibilă. Acum e restrâns la /badge/, singurul loc unde chiar e nevoie, fiindcă badge-ul e încărcat de pe site-urile clienților.

De ce nu am mers până la capăt

Politica noastră păstrează 'unsafe-inline' pe scripturi și stiluri, ceea ce e mai slab decât ce are cezic.ro. Explicația nu e că am uitat.

Site-ul e construit pe Next.js, care emite la fiecare pagină scripturi inline de hidratare. Am numărat douăzeci și două. Varianta curată cere un nonce generat la fiecare cerere, iar nonce-ul cere middleware. Middleware-ul face fiecare cerere dinamică și pierde cache-ul static de care depinde viteza site-ului acum.

Ar fi însemnat să schimbăm o îmbunătățire de securitate pe o degradare reală de viteză, pe un site care se vinde ca fiind rapid și ușor de citit de mașini. Am ales să rămânem cu politica mai slabă și să scriem de ce, în loc să afișăm un scor bun obținut cu un cost ascuns.

Pe cezic.ro problema nu apare, fiindcă acolo nu există hidratare. Un site static poate avea script-src 'self' curat. Un site cu aplicație, nu, decât cu costul de mai sus.

Cum verifici în două secunde, pe orice site

Nu ai nevoie de niciun instrument. O singură comandă îți arată tot ce trimite un server, inclusiv al furnizorului tău:

curl -sSI https://site-ul-tau.ro | grep -iE "content-security|strict-transport|x-frame|x-content|permissions-policy|referrer-policy"

Fiecare linie care lipsește e o linie de configurare nescrisă. Toate șase se pun într-o după-amiază și nu cer nicio schimbare în conținutul site-ului.

Mai departe