Connection Allowlists în Chrome 152: cum limitați serverele cu care comunică site-ul

Connection Allowlists în Chrome 152: cum limitați serverele cu care comunică site-ul. Din Chrome 152, un site poate trimite un header HTTP care spune browserului exact spre ce adrese are voie pagina să se conecteze, iar orice altă conexiune este oprită înainte să fie deschisă.

Google a prezentat funcția pe 23 septembrie 2026, pe blogul Chrome for Developers. Am testat-o pe 3 octombrie 2026 în Chrome 154 și vă arătăm ce blochează efectiv, ce poate strica și cum o introduceți fără riscuri.

Connection Allowlists în Chrome 152: cum limitați serverele cu care comunică site-ul

Majoritatea site-urilor încarcă scripturi pe care nu le-au scris: Google Tag Manager, pixeli de reclame, widgeturi de chat, pluginuri WordPress. Dacă unul dintre ele este compromis, poate trimite datele introduse de vizitatori către un server străin.

Connection Allowlists mută controlul în browser: dumneavoastră declarați destinațiile permise, iar Chrome refuză restul la nivel de rețea.

Ce este Connection Allowlists

Este un mecanism propus în grupul WICG și implementat de Chrome, prin care serverul trimite header-ul Connection-Allowlist cu o listă de tipare de adrese. Înainte de orice conexiune, browserul compară destinația cu lista și o blochează dacă nu se potrivește.

Articolul Chrome este semnat de Sebastian Benz și José Luis Zapata. Funcția a rulat ca origin trial în Chrome 148-151 și a devenit disponibilă implicit în Chrome 152, pe desktop, Android și WebView.

Conform anunțului de lansare din grupul blink-dev, publicat pe 25 iunie 2026, politica se aplică pe:

• cererile fetch și resursele paginii, adică imagini, scripturi, foi de stil și fonturi;
• navigări, redirecționări și navigările prin istoricul browserului;
• indicațiile prefetch, preconnect, preload, modulepreload și dns-prefetch;
• conexiunile WebSocket, WebRTC și WebTransport;
• documente, dedicated workers, shared workers și service workers.

Prin ce diferă de Content Security Policy

Content Security Policy controlează mai ales ce cod are voie să ruleze pe pagină. Google spune explicit în anunț că CSP nu a fost gândit să limiteze cu cine comunică pagina și că lasă neacoperite mecanisme precum navigările, WebRTC și DNS prefetch.

Diferențele practice sunt patru:

• o singură listă acoperă toate tipurile de conexiuni, în loc de directive separate precum connect-src, img-src sau font-src;
• WebRTC este blocat implicit și se permite doar cu parametrul webrtc=allow;
• redirecționările sunt blocate implicit, deci o adresă permisă nu poate trimite cererea mai departe spre una nepermisă fără redirects=allow;
• navigările sunt și ele verificate, ceea ce CSP nu face.

Cele două politici nu se exclud. Dacă o pagină trimite ambele header-e, o conexiune se deschide doar dacă trece de amândouă, iar Google recomandă Connection Allowlists ca strat suplimentar peste un CSP existent.

Sintaxa header-ului

Lista se scrie între paranteze, cu adrese în format URLPattern. Cuvântul response-origin permite automat originea care a livrat pagina, deci nu trebuie să vă scrieți propriul domeniu.

Connection-Allowlist: (response-origin "https://api.exemplu.ro/*")

Parametrii opționali se adaugă după paranteză, separați prin punct și virgulă:

Connection-Allowlist: (response-origin "https://api.exemplu.ro/*"); redirects=allow; webrtc=allow

Pentru testare există varianta care doar raportează, fără să blocheze. Rapoartele ajung la un endpoint declarat prin header-ul Reporting-Endpoints:

Reporting-Endpoints: conexiuni="https://www.exemplu.ro/rapoarte/conexiuni"
Connection-Allowlist-Report-Only: (response-origin "https://api.exemplu.ro/*"); report-to=conexiuni

Testul GOAI în Chrome 154

Am pornit pe 3 octombrie 2026 un server local care trimite header-ul și am deschis o pagină de test în Google Chrome 154.0.8037.97. Lista permitea doar originea paginii și https://www.google.com/*.

Pagina încerca șase conexiuni. Le-am rulat în trei variante: fără header, cu header activ și cu varianta Report-Only.

Conexiune	Fără header	Connection-Allowlist	Report-Only
fetch spre propriul server	reușit	reușit	reușit
imagine de pe google.com (permis)	încărcată	încărcată	încărcată
imagine de pe upload.wikimedia.org	încărcată	blocată	încărcată
fetch spre example.com	trimis	blocat	trimis
WebSocket spre echo.websocket.org	deschis	blocat	deschis
navigare din script spre example.com	pagina s-a deschis	ERR_NETWORK_ACCESS_REVOKED	pagina s-a deschis

Ultimul rând este cel mai important pentru un site obișnuit. După ce am adăugat https://example.com/* în listă, aceeași navigare s-a încărcat normal, deci blocarea vine strict din politică.

Testul are limite pe care le spunem deschis. Am verificat navigarea declanșată din JavaScript, nu un clic real pe un link, iar pentru navigator.sendBeacon am văzut doar că browserul a acceptat cererea în coadă, fără să putem confirma dacă a ajuns la destinație.

Ce poate strica pe un site real

Am comparat rezultatul cu ce încarcă astăzi goai.ro. CSP-ul nostru permite Google Tag Manager, Google Analytics și image-charts.com, iar subsolul paginii are linkuri spre Facebook, Instagram, TikTok, X, Google Maps și site-ul ANPC.

O listă construită doar din CSP ar fi lăsat pe dinafară toate aceste destinații de navigare. Mai mult, fiecare articol de pe blog trimite spre surse externe, de la documentația Google la Chromium, deci lista ar trebui să crească la fiecare publicare.

Iată situațiile în care o politică aplicată pe tot site-ul produce cele mai multe probleme:

• bloguri și site-uri de conținut cu multe linkuri externe în articole;
• magazine care folosesc procesatori de plăți cu redirecționări, de exemplu spre pagina 3-D Secure a băncii;
• site-uri cu widgeturi de chat, hărți Google sau video YouTube încorporate;
• pluginuri WordPress care încarcă fonturi sau scripturi de pe CDN-uri proprii.

Din acest motiv nu am activat header-ul pe goai.ro și nu vă recomandăm să îl activați direct pe un site de prezentare. Pentru majoritatea site-urilor, câștigul real apare pe câteva pagini izolate.

Unde are cel mai mult sens

Chiar documentația Chrome recomandă izolarea codului nesigur într-un iframe separat, cu header-ul aplicat doar acelui iframe. Așa pagina principală rămâne liberă, iar scriptul terț nu poate trimite date nicăieri în afara listei.

Câteva cazuri concrete în care merită efortul:

• pagina de checkout sau de introducere a datelor de card, unde lista destinațiilor este scurtă și cunoscută;
• panourile de administrare, de exemplu un panou Filament sau zona /wp-admin/, unde vizitatorul nu are nevoie de linkuri externe;
• aplicații web care rulează cod generat de AI sau cod încărcat de utilizatori, scenariu numit explicit de Google;
• widgeturi terțe izolate în iframe, cum ar fi un calculator de prețuri sau un formular de la alt furnizor.

Cum îl introduceți pas cu pas

Ordinea de mai jos evită paginile stricate pentru vizitatori. Începeți cu varianta care doar raportează și treceți la blocare abia după ce lista este completă.

1. Faceți inventarul conexiunilor: în Chrome DevTools, tabul Network, cu filtrul pe domenii terțe, pe paginile pe care vreți să le protejați.
2. Puneți header-ul Connection-Allowlist-Report-Only cu lista obținută și un endpoint de raportare.
3. Lăsați raportarea să ruleze cel puțin o săptămână, ca să prindă și scripturile care pornesc rar, cum ar fi cele declanșate după acordul pentru cookie-uri.
4. Adăugați în listă destinațiile legitime din rapoarte și verificați în tabul Issues din DevTools dacă header-ul este citit corect.
5. Treceți pe Connection-Allowlist doar pe paginile alese și repetați verificarea după fiecare plugin sau script nou.

Pe Apache 2.4, varianta de test se poate limita la o singură cale direct din configurația site-ului:

<If "%{REQUEST_URI} =~ m#^/checkout/#">
  Header always set Reporting-Endpoints "conexiuni=\"https://www.exemplu.ro/rapoarte/conexiuni\""
  Header always set Connection-Allowlist-Report-Only "(response-origin \"https://*.google-analytics.com/*\" \"https://www.googletagmanager.com/*\"); report-to=conexiuni"
</If>

Pe Nginx, echivalentul se pune în blocul location al paginii protejate:

location /checkout/ {
    add_header Reporting-Endpoints 'conexiuni="https://www.exemplu.ro/rapoarte/conexiuni"' always;
    add_header Connection-Allowlist-Report-Only '(response-origin "https://*.google-analytics.com/*" "https://www.googletagmanager.com/*"); report-to=conexiuni' always;
}

Google Analytics, Tag Manager și acordul pentru cookie-uri

Pe site-urile cu Google Consent Mode, scripturile de măsurare pornesc abia după acordul vizitatorului. O sesiune de test în care nu ați acceptat cookie-urile nu va arăta conexiunile spre Google Analytics, iar lista va ieși incompletă.

Testați deci în ambele stări, cu acord refuzat și cu acord acceptat. Dacă folosiți Tag Manager, fiecare etichetă nouă adăugată din contul GTM poate introduce o destinație nouă, fără nicio modificare în codul site-ului.

Suportul în browsere

La 3 octombrie 2026, funcția există doar în browserele bazate pe Chromium, de la versiunea 152. În anunțul de lansare, Mozilla și WebKit apar cu poziția „no signal", iar Microsoft Edge apare ca partener la dezvoltare.

Practic, Firefox și Safari ignoră header-ul, iar pagina se încarcă pentru acești vizitatori ca înainte. Funcția protejează deci doar o parte din trafic și nu înlocuiește curățarea scripturilor terțe sau CSP-ul.

Ce rămâne în afara protecției

Specificația WICG enumeră explicit ce nu acoperă. Atacurile XSS, consumul excesiv de memorie sau procesor și scurgerile prin canale laterale ale API-urilor web rămân în afara scopului.

Mai contează două lucruri pentru un administrator:

• dacă atacatorul poate modifica header-ele răspunsului, de exemplu printr-un server compromis, poate modifica și lista;
• un script permis rămâne permis, deci un furnizor din listă care este compromis poate primi în continuare date.

Ce facem pe GOAI în continuare

Vom urmări dacă Firefox sau Safari își schimbă poziția și vom actualiza articolul. Pentru proiectele cu checkout sau panou de administrare, introducem header-ul în modul Report-Only, apoi decidem pagină cu pagină dacă trecem la blocare.

Puteți verifica oricând ce header-e de securitate trimite site-ul dumneavoastră cu scanerul de header-e de securitate sau cu scanerul de securitate pentru website. Pentru contextul general, citiți și securitatea ca semnal de încredere din ghidul nostru SEO.

Dacă rulați WordPress, ghidurile despre securizarea unui website WordPress, detectarea și eliminarea malware-ului și atacul prin mu-plugins din 2026 arată ce tip de cod ajunge să exfiltreze date. Pentru configurarea serverului, vedeți configurarea Nginx ca reverse proxy și configurarea Cloudflare cu cPanel.

Legătura cu măsurarea este explicată în Google Consent Mode v2, iar instalarea corectă o puteți verifica cu verificarea Consent Mode. Dacă site-ul a fost deja compromis, începeți cu pașii de răspuns la incident.

Implementarea header-elor de securitate, inclusiv CSP și Connection Allowlists, face parte din serviciile de SEO tehnic și mentenanță și securitate WordPress.