# Security Header pentru site-uri: cum setați corect antetele de securitate

> Configurați antetele de securitate: CSP, HSTS, X-Content-Type-Options și altele, cu exemple pentru Nginx și Apache, plus verificare și greșeli frecvente.

Sursa: https://phpsos.de/ro/ratgeber/sicherheits-header/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Security headers sunt instrucțiuni ale serverului web către browser, care protejează vizitatorii împotriva unor atacuri precum Cross-Site Scripting, clickjacking și conexiuni necriptate. Cele mai importante sunt HSTS, Content-Security-Policy, X-Content-Type-Options, protecția împotriva cadrelor străine, Referrer-Policy și Permissions-Policy. Sunt o securizare utilă, dar nu înlocuiesc actualizările de pe server.

## Ce pot și ce nu pot security headers

La fiecare accesare a unei pagini, serverul web trimite, pe lângă conținut, și antete. Unele dintre ele controlează funcții de securitate ale browserului. Astfel se poate stabili, de exemplu, ca o pagină să fie încărcată doar prin HTTPS sau ca browserul să nu execute scripturi de la domenii străine.

Pentru operatori este importantă încadrarea: antetele protejează în primul rând vizitatorii, de exemplu împotriva interceptării sesiunilor sau a formularelor manipulate. Ele nu închid vulnerabilități pe server. O slăbiciune în PHP, în CMS sau într-o extensie rămâne, oricât de bine ar fi setate antetele. Împreună cu un cod curat, ele limitează însă sensibil consecințele multor erori.

## Cele mai importante security headers, pe scurt

| Antet | Scop | Recomandare ca punct de plecare |
|---|---|---|
| Strict-Transport-Security (HSTS) | impune HTTPS pentru accesările viitoare | `max-age=31536000; includeSubDomains` |
| Content-Security-Policy (CSP) | stabilește sursele permise pentru scripturi, imagini, cadre | individual, mai întâi ca Report-Only |
| X-Content-Type-Options | împiedică browserul să ghicească tipurile de fișiere | `nosniff` |
| X-Frame-Options sau CSP frame-ancestors | împiedică încorporarea în pagini străine (clickjacking) | `SAMEORIGIN` sau `frame-ancestors 'self'` |
| Referrer-Policy | limitează ce adresă este transmisă către alte pagini | `strict-origin-when-cross-origin` |
| Permissions-Policy | dezactivează funcții ale browserului precum camera sau locația | permiteți doar funcțiile necesare |

HSTS ar trebui să-l setați abia când toate subdomeniile sunt accesibile în mod fiabil prin HTTPS. Browserul reține instrucțiunea pentru durata indicată; o greșeală nu mai poate fi retrasă imediat. Începeți, la nevoie, cu o durată scurtă și măriți-o după teste reușite. Opțiunea suplimentară `preload` înscrie domeniul permanent în listele producătorilor de browsere și ar trebui setată doar după o verificare atentă.

Antetele nu sunt, în plus, singurul loc în care browserul oferă protecție. Cookieurile ar trebui să poarte atributele `Secure`, `HttpOnly` și `SameSite`, pentru ca sesiunile să nu poată fi interceptate prin conexiuni necriptate sau prin scripturi. Cum setați acest lucru în PHP descrie ghidul despre sesiuni.

## Setarea security headers în Nginx

În Nginx, antetele aparțin blocului `server` al site-ului respectiv. Adaosul `always` face ca ele să fie trimise și la paginile de eroare.

```nginx
server {
    # ...
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'" always;

    server_tokens off;
}
```

O particularitate a Nginx: dacă un bloc `location` setează propriile instrucțiuni `add_header`, antetele din blocul `server` nu sunt preluate acolo. Verificați de aceea și subpaginile și fișierele statice. Alte măsuri de securizare pentru această combinație descrie [Cum securizați Nginx cu PHP-FPM](https://phpsos.de/ro/server/nginx-php-fpm/).

## Setarea security headers în Apache

Pe Apache aveți nevoie de modulul `mod_headers`. Instrucțiunile aparțin VirtualHost sau, dacă nu aveți acces la acesta, `.htaccess`.

```apache
<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    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"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

ServerTokens Prod
ServerSignature Off
```

`ServerTokens` și `ServerSignature` aparțin configurației principale. Ele împiedică serverul să-și indice versiunea exactă în răspunsuri și în paginile de eroare. În `php.ini` obțineți același lucru pentru PHP cu `expose_php = Off`.

## Introducerea treptată a Content-Security-Policy

Content-Security-Policy este cel mai eficient, dar și cel mai pretențios antet. Ea stabilește din ce surse pot fi încărcate scripturi, stylesheeturi, imagini, fonturi și cadre. Dacă un script introdus este descărcat de la un domeniu străin, browserul îl blochează.

Site-urile moderne integrează adesea instrumente de analiză, furnizori de plăți, servicii de hărți sau videoclipuri. O politică prea strictă paralizează atunci funcții. Procedați de aceea în trepte:

- Începeți mai întâi cu `Content-Security-Policy-Report-Only`. Browserul raportează încălcările în consola de dezvoltator sau la o adresă colectoare, dar nu blochează nimic.
- Inventariați toate sursele necesare și aprobați-le țintit, în loc să folosiți substituenți generali.
- Mutați treptat scripturile inline în fișiere sau dotați-le cu nonce, pentru a putea renunța la `'unsafe-inline'`.
- Abia după o fază de test fără mesaje neașteptate treceți la `Content-Security-Policy`.

> **Sfat:**
> CSP completează escaping-ul curat din cod, dar nu îl înlocuiește. Cum securizați corect ieșirile în PHP se află în ghidul [Cum preveniți Cross-Site Scripting în PHP](https://phpsos.de/ro/ratgeber/xss-php/).

## Verificarea antetelor și evitarea greșelilor tipice

După fiecare modificare ar trebui să verificați dacă antetele ajung efectiv. Se poate face fără instrumente suplimentare, cu `curl`:

```bash
# Testați configurarea și reîncărcați
nginx -t && systemctl reload nginx

# Afișați antetele paginii de start și ale unui fișier static
curl -sI https://www.example.de/ | grep -iE 'strict|content-security|x-content|x-frame|referrer|permissions|server'
curl -sI https://www.example.de/favicon.ico | grep -iE 'strict|x-content'
```

Greșeli tipice sunt antetele setate de două ori, când serverul web și aplicația trimit aceleași antete, un CDN din față care elimină sau suprascrie antete și antetele care apar doar pe pagina de start, dar nu la redirecționări sau la paginile de eroare. Verificați, de asemenea, după actualizările CMS-ului sau ale extensiilor de securitate dacă antetele s-au schimbat.

Stabiliți de aceea un singur loc în care antetele sunt întreținute, cel mai bine serverul web sau serviciul din față. Multe extensii CMS oferă și ele setări pentru security headers. Este comod, dar duce ușor la indicații duble sau contradictorii, dacă serverul setează în plus antete. Pentru teste individuale sunt potrivite și instrumentele de dezvoltare ale browserului: în fila Network vedeți pentru fiecare cerere antetele răspunsului, iar consola afișează încălcările Content-Security-Policy.

## Cum ajută PHP SOS concret?

- Verificăm antetele actuale ale tuturor site-urilor dumneavoastră, inclusiv în spatele CDN și proxy, și arătăm lacunele și contradicțiile.
- Setăm antetele central în serverul web, în cadrul [securizării serverului](https://phpsos.de/ro/leistungen/server-haertung/), și testăm pagina de start, subpaginile și paginile de eroare.
- Introducem Content-Security-Policy în modul Report-Only, evaluăm mesajele și o activăm ferm după consultare.
- Acolo unde modificările de cod nu sunt posibile imediat, completăm protecția cu [reguli WAF și patching virtual](https://phpsos.de/ro/leistungen/waf-virtuelles-patching/).


## Întrebări frecvente

**Ce sunt security headers?**  
Security headers sunt indicații suplimentare din răspunsul serverului web. Ele îi spun browserului, de exemplu, să încarce pagina doar prin HTTPS, să nu execute scripturi străine sau să nu afișeze pagina în cadre străine. Ele protejează în primul rând vizitatorii.

**Protejează security headers împotriva PHP2Shell?**  
Nu. PHP2Shell este o vulnerabilitate din PHP de pe server, antetele acționează în browserul vizitatorului. Împotriva PHP2Shell ajută actualizarea la o versiune PHP corectată și repornirea tuturor workerilor. Antetele sunt o securizare complementară pentru alte tipuri de atac.

**Poate o Content-Security-Policy să-mi strice site-ul?**  
Da, o politică prea strictă blochează scripturi, fonturi sau conținut încorporat necesare. De aceea se introduce mai întâi în modul Report-Only, se evaluează mesajele și abia apoi se trece la aplicare.

**Mai are sens X-XSS-Protection?**  
Nu. Browserele actuale nu mai evaluează acest antet, iar recomandarea este să fie omis sau setat pe 0. Protecție împotriva Cross-Site Scripting oferă escaping curat în cod și o Content-Security-Policy.

## Surse

- [OWASP Cheat Sheet Series (HTTP Headers)](https://cheatsheetseries.owasp.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [BSI: recomandări pentru servere web](https://www.bsi.bund.de/)