Content Security Policy avansat pentru WordPress: configurare și testare

Content Security Policy (CSP) este un header HTTP care instruiește browserul să execute doar resurse din surse explicit autorizate, blocând automat execuția oricărui script injectat prin XSS, indiferent dacă vulnerabilitatea există sau nu. Este singura măsură de apărare care reduce impactul unui atac XSS reușit, nu doar probabilitatea atacului.

WordPress face configurarea CSP mai complexă decât pe alte platforme, deoarece editorul Gutenberg, temele și numeroase plugin-uri folosesc scripturi și stiluri inline pe care un CSP strict le-ar bloca. Configurarea corectă necesită echilibrarea securității cu funcționalitatea.

Content Security Policy avansat pentru WordPress: configurare și testare

Un CSP prost configurat poate rupe complet funcționalitatea site-ului: editorul WordPress nu mai funcționează, imaginile nu se încarcă, plugin-urile de plată eșuează. Un CSP corect configurat blochează exact ce trebuie și permite tot ce este legitim.

Abordarea recomandată este să porniți întotdeauna în modul raportare (Content-Security-Policy-Report-Only) înainte de a activa blocarea reală.

Directivele CSP esențiale pentru WordPress

Înțelegerea directivelor este fundamentală pentru configurare corectă:

• default-src – regula implicită pentru toate tipurile de resurse care nu au directivă specifică.
• script-src – controlează de unde pot fi încărcate scripturile JavaScript.
• style-src – controlează sursele pentru foile de stil CSS.
• img-src – controlează sursele permise pentru imagini.
• font-src – controlează sursele permise pentru fonturi.
• frame-src – controlează sursele permise pentru iframe-uri.
• connect-src – controlează la ce URL-uri pot face cereri XMLHttpRequest, fetch și WebSocket.
• report-uri / report-to – URL unde browserul trimite rapoarte despre violările CSP.

Problema unsafe-inline în WordPress

Principala tensiune în configurarea CSP pentru WordPress este că editorul Gutenberg și multe plugin-uri folosesc JavaScript și CSS inline, care sunt blocate implicit de orice CSP restrictiv. Soluțiile disponibile sunt:

Nonces CSP (recomandat)

WordPress 5.0+ suportă nonces CSP care permit scripturi și stiluri inline specifice, identificate printr-un token unic generat la fiecare cerere. WordPress include funcționalitate nativă pentru acest lucru:

// In functions.php
add_filter( 'wp_headers', function( $headers ) {
    $nonce = base64_encode( random_bytes( 16 ) );
    // Stocati nonce-ul pentru utilizare in CSP
    $GLOBALS['csp_nonce'] = $nonce;

    $headers['Content-Security-Policy'] =
        "default-src 'self'; " .
        "script-src 'self' 'nonce-{$nonce}' https://www.google.com https://www.gstatic.com; " .
        "style-src 'self' 'nonce-{$nonce}' https://fonts.googleapis.com; " .
        "font-src 'self' https://fonts.gstatic.com; " .
        "img-src 'self' data: https:; " .
        "frame-src https://www.google.com; " .
        "report-uri /csp-report-endpoint";
    return $headers;
});

Hashes pentru scripturi statice

Pentru scripturi inline care nu se schimbă, puteți folosi hash-ul SHA-256 al conținutului în loc de unsafe-inline:

# Calcularea hash-ului pentru un script inline
echo -n 'console.log("test");' | openssl dgst -sha256 -binary | openssl base64

Includeți hash-ul în CSP: script-src 'sha256-HASH_CALCULAT'.

Configurarea în modul raportare

Porniți întotdeauna cu Content-Security-Policy-Report-Only pentru a identifica violările fără să blocați traficul legitim:

// In functions.php
add_filter( 'wp_headers', function( $headers ) {
    $headers['Content-Security-Policy-Report-Only'] =
        "default-src 'self'; " .
        "script-src 'self' 'unsafe-inline'; " .
        "style-src 'self' 'unsafe-inline'; " .
        "img-src 'self' data: https:; " .
        "report-uri https://site-vostru.ro/csp-report";
    return $headers;
});

// Endpoint pentru colectarea rapoartelor
add_action( 'init', function() {
    if ( strpos( $_SERVER['REQUEST_URI'], '/csp-report' ) !== false
         && $_SERVER['REQUEST_METHOD'] === 'POST' ) {
        $report = file_get_contents( 'php://input' );
        error_log( 'CSP Report: ' . $report );
        exit;
    }
});

Analiza rapoartelor și rafinarea politicii

Monitorizați rapoartele CSP timp de cel puțin o săptămână, acoperind toate tipurile de utilizare ale site-ului. Rapoartele relevă sursele blocate legitime pe care trebuie să le adăugați în politică înainte de activarea blocării reale.

Servicii ca report-uri.com sau sentry.io pot agrega și vizualiza rapoartele CSP pentru a identifica mai ușor pattern-urile.

Trecerea de la raportare la blocare

Doar după ce nu mai primiți rapoarte pentru resurse legitime, schimbați headerul din Content-Security-Policy-Report-Only în Content-Security-Policy. Monitorizați atent primele 24-48 de ore după activare pentru erori funcționale raportate de utilizatori sau pentru mesaje de eroare JavaScript în consola browserului.

Concluzie

CSP corect configurat este cel mai eficient mecanism de apărare împotriva XSS disponibil în 2026. Procesul de configurare necesită răbdare și testare sistematică, dar rezultatul este o reducere dramatică a impactului potențial al oricărui atac XSS reușit pe site-ul dumneavoastră WordPress.

Serviciile noastre de audit securitate WordPress includ evaluarea și configurarea CSP optimizată pentru configurația specifică a site-ului dumneavoastră, inclusiv testarea completă a funcționalității după activare.