Gepubliceerd: 16 april 2026
Omdat webapplicaties steeds complexer worden, met name door de opkomst van geïntegreerde generatieve AI, is de bescherming van gebruikersgegevens een topprioriteit. Daarom kondigen we de origin-proef aan voor Connection Allowlists, een nieuw beveiligingsmechanisme dat een netwerksandbox creëert voor documenten en workers.
Achtergrond
In een modern web-ecosysteem bewegen gevoelige gegevens zich constant tussen clients en servers. Deze mobiliteit, in combinatie met een complexe toeleveringsketen van scripts van derden en de opkomst van dynamisch gegenereerde code door generatieve AI, verhoogt het risico op datalekken aanzienlijk.
Kwaadaardige scripts, kwetsbaarheden in gebundelde bibliotheken of onbedoeld gedrag in door AI gegenereerde code kunnen beveiligingscontroles op applicatieniveau omzeilen en gevoelige informatie naar ongeautoriseerde eindpunten verzenden. Hoewel Content Security Policy (CSP) een krachtig hulpmiddel is om te bepalen wat een pagina kan laden en uitvoeren, kan het lastig zijn om de complexiteit ervan te beheersen en specifiek te beperken waar een pagina mee communiceert . Dit leidt vaak tot algemene beleidsregels die ruimte laten voor ongeautoriseerde netwerkactiviteit.
Verbindingstoegangslijsten-sandbox
Verbindingslijsten bieden een directe manier om deze risico's aan te pakken door de browser de poortwachter te maken van alle netwerkverbindingen die afkomstig zijn van uw pagina. Door de HTTP-antwoordheader ` Connection-Allowlist op te nemen, specificeert een site de exacte URL-patronen die zijn toegestaan voor alle netwerkcommunicatie die wordt geïnitieerd door de context ervan, zoals een document of een webworker.
Deze functie dwingt een firewall op frameworkniveau af die standaard verbindingen blokkeert. Voordat er een verbinding tot stand komt, bijvoorbeeld voor het ophalen van een subresource, een navigatie-omleiding of een WebSocket-verbinding, controleert de browser de bestemming aan de hand van de whitelist. Als het eindpunt niet overeenkomt, blokkeert de browser de verbinding op netwerkniveau. De browser handhaaft de netwerkgrenzen, zelfs als kwaadwillende code probeert de logica op applicatieniveau te omzeilen.
Hoe verbindingstoegangslijsten werken
Verbindingslijsten bieden een directe manier om deze risico's aan te pakken door de browser de poortwachter te maken van alle netwerkverbindingen die afkomstig zijn van uw pagina. Door de HTTP-antwoordheader ` Connection-Allowlist op te nemen, specificeert een site de exacte URL-patronen die zijn toegestaan voor alle netwerkcommunicatie die door de context ervan wordt geïnitieerd. Voor de oorspronkelijke test wordt dit alleen ondersteund voor documentcontexten.
Voordat er een verbinding tot stand komt, bijvoorbeeld voor het ophalen van een subresource, een navigatie-omleiding of een WebSocket-verbinding, controleert de browser de bestemming aan de hand van de whitelist. Als het eindpunt niet overeenkomt, blokkeert de browser de verbinding op netwerkniveau. Dit zorgt ervoor dat netwerkgrenzen worden gehandhaafd, zelfs als kwaadwillende code probeert de applicatielogica te omzeilen.
Gebruik het response-origin token
Je kunt het response-origin -token gebruiken, waarmee de oorsprong van waaruit het antwoord wordt verzonden dynamisch aan de whitelist wordt toegevoegd:
Connection-Allowlist: ("https://api.example.com/*" response-origin)
In dit voorbeeld kan de pagina verbinding maken met elk pad op de oorspronkelijke pagina en het opgegeven API-eindpunt.
Meld overtredingen
Om potentiële problemen te monitoren zonder de functionaliteit van uw site te verstoren, kunt u de header Connection-Allowlist-Report-Only gebruiken. Deze variant analyseert het beleid en stuurt meldingen van overtredingen naar een specifiek eindpunt via de Reporting API .
Connection-Allowlist: ("https://trusted.com/*"); report-to=security-endpoint
Belangrijkste gebruiksscenario's
Verbindingstoegangslijsten zijn handig in omgevingen met hoge beveiligingseisen of dynamische omgevingen:
- Generatieve AI en onbetrouwbare code: Als uw site gebruikers toestaat gegenereerde of onbetrouwbare code uit te voeren, bijvoorbeeld in Sheets Canvas of ontwikkelomgevingen, kunnen verbindingslijsten voorkomen dat de code gegevens naar externe domeinen doorstuurt.
- Toezicht door derden: U kunt ervoor zorgen dat zelfs als een script van een derde partij gecompromitteerd raakt, het geen gegevens naar ongeautoriseerde servers kan verzenden.
- Architectonische beveiligingsmaatregelen: Handhaaf een strikte netwerkgrens voor gevoelige onderdelen van uw applicatie en zorg ervoor dat communicatie alleen plaatsvindt met goedgekeurde backends.
Verschillen met Content Security Policy
Hoewel verbindingstoegangslijsten en CSP vergelijkbare doelen hebben, vullen ze elkaar aan:
- Focus op netwerkniveau: Verbindingslijsten richten zich op de bestemming van netwerkverbindingen, in plaats van op de manier waarop een bron wordt geladen of uitgevoerd.
- Uitgebreide dekking: Het behandelt navigatie, omleidingen en diverse webplatform-API's, zoals Fetch, WebRTC, WebTransport, DNS-prefetch en preload, op een uniforme manier.
- Vereenvoudigde syntaxis: Verbindingstoegangslijsten richten zich op één enkele taak, wat de configuratie en beveiligingscontrole vereenvoudigt.
Experimenteer met toegangslijsten voor verbindingen.
De functie 'Verbindingstoegangslijsten' is beschikbaar voor lokale tests. De testfase loopt van Chrome versie 148 tot en met Chrome versie 151. Er wordt gedurende de testfase continu nieuwe functionaliteit toegevoegd. Aan het begin van deze testfase is de rapportagefunctionaliteit beperkt tot documentcontexten; Dedicated, Shared en Service Workers worden niet ondersteund. Meer informatie over wat wel wordt ondersteund vindt u in het gedeelte 'Registreren voor de testfase' .
Test lokaal
- Schakel de vlag in: Open Chrome en ga naar
chrome://flags/#connection-allowlist. Stel de vlag in op Ingeschakeld . - Implementeer de header: Configureer uw lokale ontwikkelserver om de HTTP-antwoordheader `
Connection-Allowlistte verzenden. Bijvoorbeeld: `Connection-Allowlist: ("https://api.example.com/*" response-origin). - Controleer met DevTools: Open Chrome DevTools en voer acties uit die netwerkverzoeken activeren.
- Netwerkpaneel : Controleer op verzoeken die "geblokkeerd: overig" zijn of een verbindingsfout weergeven.
- Tabblad Problemen : Raadpleeg gedetailleerde rapporten als er parseerfouten in uw header zijn opgetreden.
Meld je aan voor de Origin-proef.
Hoewel lokaal testen geweldig is voor de ontwikkelomgeving, moet u zich registreren voor de Origin-proefversie om verbindingslijsten voor uw gebruikers in de productieomgeving in te schakelen.
- Ga naar het dashboard voor Chrome Origin-proefversies .
- Zoek de oorsprongsproef van de verbindingstoegangslijsten en klik op Registreren .
- Voeg het gegenereerde token toe aan de pagina's of headers van uw site, zoals beschreven in de handleiding 'Aan de slag met Origin-proefversies' .
De testfase loopt van Chrome versie 148 tot en met Chrome versie 151. Er wordt continu functionaliteit toegevoegd naarmate de testfase vordert, dus we raden u ten zeerste aan om uw bestaande webbeveiligingsmechanismen te blijven gebruiken tijdens het testen van Connection Allowlists. In de Intent to Experiment worden de netwerkeindpunten die onder de implementatie van Connection Allowlists vallen verder toegelicht.
Geef feedback
Geef feedback over het ontwerp en de bruikbaarheid van de functie. Als je problemen ondervindt of suggesties voor verbeteringen hebt, neem dan contact op met het team.
- GitHub : Open een issue of reageer op een bestaand issue in de
WICG/connection-allowlistsrepository. - Chromium-bugtracker : Maak een probleem aan in de Chromium-bugtracker .