Defaults.Exposed › Remedieri › Content-Security-Policy (CSP)

Cum să remediezi Content-Security-Policy (CSP)

O Politică de Securitate a Conținutului este o regulă de siguranță pe care site-ul tău o transmite browserului fiecărui vizitator, spunându-i exact ce cod are voie să ruleze. Fără ea, dacă ceva rău ajunge vreodată pe o pagină — printr-o casetă de comentarii, un plugin spart sau un script terț — browserul îl va rula liber, inclusiv codul care în tăcere colectează numerele de card și parolele clienților tăi pe măsură ce le tastează, cu lacătul în continuare afișat.

Concluzia pentru afacerea ta: Dacă site-ul tău este vreodată modificat, codul malițios poate citi detaliile de card de plată și autentificările clienților tăi direct de pe pagina ta de plată în timp ce totul arată complet normal — lăsându-te cu dispute, reclamații de fraudă, o breșă de date raportabilă și un eșec de verificare pe care echipele de securitate ale clienților mai mari îl folosesc pentru a bloca sau ucide o tranzacție.

Ce te poate costa

• Codul ascuns ajunge pe una din paginile tale și copiază în tăcere fiecare număr de card și parolă pe care clienții tăi le introduc la plată, trimițându-le unui atacator în timp ce site-ul tău arată complet normal — afli numai când sosesc reclamațiile de fraudă.
• Un escroc plantează un formular fals 'plătește aici' pe site-ul tău real care captează plăți în propriul său cont; clienții cred că te-au plătit, te învinuiesc când bunurile nu vin niciodată și cer banii înapoi.
• Echipa de securitate a unui client mai mare scanează site-ul tău, vede că această protecție de bază este dezactivată și o semnalează — blocând sau pierzând tranzacția până când poți dovedi că este remediată.
• O breșă urmărită la o garanție standard lipsă devine un incident raportabil: întrebări de la regulator, notificări pentru clienți și un impact de reputație care costă mult mai mult decât remedierea gratuită.

De ce contează. Lacătul dovedește că conexiunea la site-ul tău este privată, dar nu face nimic pentru a controla ce cod rulează odată ce un vizitator este pe pagină. O Politică de Securitate a Conținutului este garanția care face asta — spune browserelor să ignore orice script care nu a venit dintr-o sursă pe care o ai încredere, astfel că un singur câmp modificat, anunț sau plugin nu poate fi transformat într-un instrument pentru furtul banilor și datelor clienților tăi. Este o verificare notată pe foaia ta de punctaj, valorând puncte reale, și este unul din primele lucruri pe care le caută o revizuire profesionistă de securitate.

Ce este, în cuvinte simple

Când cineva vizitează site-ul tău, browserul descarcă pagina ta și rulează orice cod este pe ea — scripturile care fac meniurile să se deschidă, butoanele să funcționeze, formularele de plată să se trimită și așa mai departe. Implicit, browserul le are pe toate de încredere. Nu are nicio modalitate de a ști ce cod este cu adevărat al tău și ce a fost introdus de altcineva.

O Politică de Securitate a Conținutului (adesea abreviată CSP) este o scurtă listă de reguli pe care site-ul tău o atașează la fiecare pagină, spunând browserului: “rulează numai cod din aceste surse pe care le-am aprobat și refuză orice altceva.” Este diferența dintre o discotecă care lasă pe oricine înăuntru și una cu o listă de invitați la ușă.

Motivul pentru care aceasta contează atât de mult este că site-urile web sunt modificate constant — nu întotdeauna prin piratarea serverului tău, ci prin ușile din spate pe care cele mai multe site-uri le lasă deschise: un câmp de comentarii, o casetă de căutare, un plugin depășit, un script terț pentru anunțuri sau analiză sau un widget de chat. Dacă un atacator obține chiar și o linie din propriul lor cod pe una din paginile tale, browserul îl rulează ca și cum ar fi al tău. De acolo poate citi tot ce tastează clienții tăi — numere de card, parole, adrese — și le poate trimite în tăcere în altă parte.

Ce te poate costa

Aceasta nu este abstractă. Atacul pe care o Politică de Securitate a Conținutului îl previne — codul injectat într-o pagină care fură date de la clienții tăi — se află în spatele unora din cele mai mari breșe de colectare de carduri din dosare. Iată cum tinde să se desfășoare pentru o afacere normală:

• Skimmer-ul invizibil la plată. Un atacator introduce câteva linii de cod pe pagina ta de plată printr-un plugin vulnerabil sau un script terț compromis. Fiecare număr de card, nume și CVV pe care le tastează clienții tăi este copiat și trimis atacatorului în timp real. Site-ul tău arată și funcționează perfect; lacătul este acolo. Descoperi asta săptămâni mai târziu când furnizorul tău de plăți sună despre un grup de rapoarte de fraudă care urmăresc toate până la magazinul tău.

• Formularul fals de plată. Un escroc injectează o casetă convingătoare “plătește aici” pe site-ul tău real. Clienții introduc detaliile lor de încredere cu brandul tău; banii și datele merg la atacator. Clienții te învinuiesc — și nu greșesc să o facă, deoarece s-a întâmplat pe site-ul tău.

• Contractul pierdut. Echipa de securitate a unui prospect mai mare rulează o scanare automată a site-ului tău ca parte a due diligence pentru furnizori. O Politică de Securitate a Conținutului lipsă apare imediat ca un decalaj de severitate ridicată. Pentru un revizuitor de achiziții sau securitate, acea singură garanție lipsă se citește ca “acest furnizor nu face elementele de bază” — și tranzacția se blochează în timp ce cer remediere sau merge în liniște la un concurent care a trecut.

• Breșa raportabilă. Când o breșă de date este urmărită până la o garanție standard gratuită lipsă, nu mai este un ghinion și începe să arate ca neglijență. Aceasta schimbă întrebările regulatorului, obligația de notificare a clienților și costul.

• Anunțul sau widget-ul compromis. Multe site-uri încarcă cod de la părți externe — rețele de anunțuri, fonturi, chat de suport, analiză. Dacă oricare din acestea este compromis, codul malițios se strecoară direct în paginile tale. O Politică de Securitate a Conținutului limitează raza de explozie permițând numai sursele externe specifice în care ai încredere.

Ce este de fapt (detaliul)

O Politică de Securitate a Conținutului este livrată ca un singur antet de răspuns HTTP — o linie pe care serverul tău web o trimite cu fiecare pagină. Valoarea sa este un set de directive, fiecare denumind un tip de conținut și sursele permise pentru el. De exemplu:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

În termeni simpli, aceasta spune: implicit încarcă lucruri numai de pe propriul meu site; rulează scripturi numai de pe propriul meu site; nu permite pluginuri de stil vechi; și nu lasă alte site-uri să încorporeze al meu într-un cadru.

Cum arată “bine”. Verificarea noastră nu caută numai prezența antetului — citește politica directivă cu directivă și notează cât de puternică este de fapt. O politică puternică:

• Setează o linie de bază restrictivă (default-src 'self') și o lărgește numai pentru terțe părți de încredere specifice pe care le folosești de fapt.
• Evită golurile. Nu folosește 'unsafe-inline' sau 'unsafe-eval' pentru scripturi și nu folosește surse wildcard (*) sau surse cu scheme goale (precum https:) pentru scripturi. Unde scripturile inline sunt cu adevărat necesare, folosește un nonce sau hash astfel că numai codul tău specific aprobat rulează.
• Blochează cadrele cu frame-ancestors 'self' și dezactivează pluginurile moștenite cu object-src 'none'.
• Este în aplicare, nu numai-raport. Un antet Content-Security-Policy-Report-Only numai urmărește; nu oferă zero protecție la timp de rulare. Verificarea noastră îi acordă o mică fracțiune din credit și nu înregistrează niciodată ca trecere. Ești protejat numai odată ce politica este în aplicare.

Cum se remediază (gratuit, ~1–2 ore)

Predă asta persoanei tale IT sau celui care rulează site-ul tău — remedierea în sine este complet gratuită. Percepem taxe numai pentru monitorizarea că rămâne activă și corectă în timp; activarea nu costă nimic. Motivul pentru care aceasta durează o oră sau două mai degrabă decât minute este pasul de trial atent care o oprește să blocheze accidental părți ale propriului tău site.

1. Începe în modul numai-raport — nu aplica încă. Adaugă un antet de răspuns Content-Security-Policy-Report-Only. Aceasta urmărește și înregistrează ce ar fi blocat fără a bloca nimic efectiv, astfel că site-ul live continuă să funcționeze în timp ce înveți de ce depinde cu adevărat fiecare pagină.

2. Construiește politica din ce utilizează de fapt site-ul tău. Revizuiește rapoartele pentru a găsi fiecare sursă legitimă de scripturi, stiluri, fonturi și imagini — propriul domeniu, analitica ta, furnizorul de plăți, gazda de fonturi, widget-ul de chat — și listează-le ca surse permise. Un punct de plecare solid este default-src 'self' plus intrări explicite pentru terțele de încredere pe care le folosești de fapt.

3. Evită golurile care înfrâng tot scopul. Evită 'unsafe-inline' și 'unsafe-eval' pentru scripturi și evită surse wildcard precum * și scheme goale precum https: pentru scripturi. Unde scripturile inline sunt inevitabile, folosește un nonce sau hash.

4. Blochează cadrarea și pluginurile. Adaugă frame-ancestors 'self' (aceasta oprește de asemenea alte site-uri să le încorporeze pe ale tale pentru a-ți înșela clienții) și object-src 'none' pentru a bloca atacuri bazate pe pluginuri moștenite.

5. Comută de la numai-raport la aplicare. Odată ce rapoartele sunt curate și site-ul funcționează, schimbă numele antetului din Content-Security-Policy-Report-Only în Content-Security-Policy. Acesta este pasul care livrează de fapt protecție — o politică numai-raport nu o face și nu va trece verificarea.

   Unde setezi antetul depinde de platforma ta:

   • Cloudflare: Reguli → Reguli de transformare → Modifică antetul de răspuns → setează Content-Security-Policy.
   • Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
   • Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
   • IIS (web.config): adaugă un antet de răspuns HTTP personalizat denumit Content-Security-Policy cu politica ca valoare.

6. Reverificați domeniul pentru a confirma că politica apare acum ca activată și în aplicare, fără goluri slăbitoare.

Greșeli comune

• Oprirea la numai-raport. Cea mai frecventă eroare unică: o politică este adăugată în modul numai-raport, toată lumea trece mai departe, iar site-ul nu este niciodată protejat de fapt. Numai-raport nu blochează nimic. Trebuie să comutezi la aplicare.
• Apelând la 'unsafe-inline' pentru a o face “să funcționeze pur și simplu.” Când politica blochează un script inline legitim, remedierea rapidă este de a permite toate scripturile inline — dar aceasta redeschide exact gaura pe care politica era menită să o închidă. Folosește în schimb un nonce sau hash.
• Folosind un wildcard. Un simplu * (sau https:) în script-src permite scripturi de oriunde, ceea ce înseamnă că politica nu oferă aproape nicio protecție reală.
• Uitând sursele terțe. Aplicarea unei politici stricte fără a lista mai întâi serviciile externe legitime pe care le folosești poate rupe părți ale propriului tău site — exact de aceea există pasul de trial numai-raport.
• Setând-o numai pe homepage. Politica trebuie să acopere fiecare pagină, în special plata, autentificarea și paginile de cont — acelea merită atacate.
• Tratând-o ca înlocuitor pentru lacăt. O Politică de Securitate a Conținutului și HTTPS/HSTS protejează lucruri diferite. Vrei pe toate; una nu o acoperă pe alta.

Întrebări frecvente