[{"data":1,"prerenderedAt":285},["ShallowReactive",2],{"blog-tag-nl-security-headers":3},{"tagName":4,"posts":5},"Security Headers",[6,141],{"id":7,"title":8,"author":9,"body":10,"category":4,"date":107,"description":108,"extension":109,"faq":110,"meta":129,"navigation":130,"path":131,"readingTime":132,"seo":133,"slug":134,"stem":135,"tags":136,"__hash__":140},"blog\u002Fblog\u002Fnl\u002Fwhat-is-cross-origin-opener-policy.md","Wat is de Cross-Origin-Opener-Policy header en waarom is die belangrijk?","EuroraCloud Team",{"type":11,"value":12,"toc":96},"minimark",[13,17,21,26,29,32,36,39,42,46,49,52,56,59,62,66,69,72,76,79,89,93],[14,15,8],"h1",{"id":16},"wat-is-de-cross-origin-opener-policy-header-en-waarom-is-die-belangrijk",[18,19,20],"p",{},"De Cross-Origin-Opener-Policy header, meestal geschreven als COOP, is een response header die bepaalt of je pagina een venstersamenhang deelt met pagina's van andere origins. Ingesteld op same-origin isoleert hij je document in een eigen browsing context group, zodat een pagina van een andere origin die de jouwe opent, of die jij opent, geen scriptbare verwijzing terug naar je venster kan behouden. Dit sluit een klasse van cross-origin aanvallen die bekendstaan als XS-Leaks en side-channel aanvallen, en het is bovendien de instelling die bepaalde krachtige browserfuncties ontgrendelt.",[22,23,25],"h2",{"id":24},"waarom-bestaat-de-cross-origin-opener-policy-header","Waarom bestaat de Cross-Origin-Opener-Policy header?",[18,27,28],{},"COOP bestaat omdat het openen van een venster een verband creëert dat misbruikt kan worden. Wanneer de ene pagina de andere opent met window.open(), of een pagina de jouwe opent, kan de browser via de eigenschap window.opener een verwijzing tussen de twee vensters behouden. Als die twee pagina's van verschillende origins komen, wordt die verwijzing een route waarlangs een cross-origin pagina de jouwe kan aftasten.",[18,30,31],{},"De aanvallen die dit mogelijk maakt zijn subtiel. Ze stelen je gegevens niet rechtstreeks, maar leiden ze af via side channels, timing en gedeelde browserstatus, in een familie van technieken die de securitygemeenschap XS-Leaks noemt. Volgens de documentatie van Mozilla is COOP specifiek geïntroduceerd zodat een site kan garanderen dat zijn top-level document geen browsing context group deelt met cross-origin documenten, en dat is precies wat die verwijzing verbreekt en de route afsluit.",[22,33,35],{"id":34},"wat-doet-de-cross-origin-opener-policy-header-eigenlijk","Wat doet de Cross-Origin-Opener-Policy header eigenlijk?",[18,37,38],{},"COOP bepaalt of je document en de pagina's waarmee het interacteert tot dezelfde browsing context group behoren, het interne browserbegrip dat bepaalt of twee vensters elkaar kunnen scripten. Als je hem strikt instelt, gaat je venster in een eigen groep en verliest elk cross-origin venster zijn verwijzing naar het jouwe.",[18,40,41],{},"De header kent een kleine set waarden. De standaardwaarde, unsafe-none, past geen isolatie toe en laat je document een browsing context group delen met cross-origin pagina's. De strikte waarde, same-origin, isoleert je document zo dat alleen same-origin pagina's die zelf ook same-origin instellen in dezelfde groep kunnen blijven. Een tussenwaarde, same-origin-allow-popups, behoudt die isolatie maar laat popups die je zelf opent gewoon functioneren, wat de praktische keuze is voor sites die afhankelijk zijn van popup-flows zoals betaling of single sign-on. Wanneer een cross-origin venster onder same-origin wordt geopend, wordt zijn window.opener null, zodat de verwijzing simpelweg niet bestaat.",[22,43,45],{"id":44},"wat-gebeurt-er-als-je-hem-niet-instelt","Wat gebeurt er als je hem niet instelt?",[18,47,48],{},"Zonder COOP is de standaard unsafe-none, wat betekent dat er geen isolatie is en de vensterverwijzing openblijft. Een cross-origin pagina die de jouwe opent, of die jij opent, kan een greep op je venster behouden en die gebruiken als opstap voor de hierboven beschreven side-channel technieken.",[18,50,51],{},"Dit is een stil gat, geen luid gat. Niets op je site lijkt kapot, en de meeste bezoekers zullen het nooit veroorzaken, en juist daarom blijft het vaak onaangepakt. Maar voor een site die iets gevoeligs verwerkt, een login, een patiëntenportaal, een betaalstap, is het openlaten van de venstersamenhang een vermijdbare blootstelling, en het is er een die securityscanners en audits steeds vaker aanmerken als een ontbrekende header.",[22,53,55],{"id":54},"hoe-implementeer-je-de-cross-origin-opener-policy-header","Hoe implementeer je de Cross-Origin-Opener-Policy header?",[18,57,58],{},"Je stelt COOP in als één HTTP response header. Voor de meeste sites is de juiste startwaarde Cross-Origin-Opener-Policy: same-origin-allow-popups, die je isolatie geeft terwijl popup-flows behouden blijven; een site zonder zulke afhankelijkheden kan naar de striktere same-origin. Hij kan worden toegevoegd op de webserver, in de applicatielaag, of aan de rand in een CDN of securitylaag die voor de site staat.",[18,60,61],{},"De enige sterke aanbeveling is: test voordat je afdwingt. COOP ondersteunt een report-only modus, verstuurd als Cross-Origin-Opener-Policy-Report-Only, die de browser Reporting API gebruikt om je te laten weten wat de policy zou breken zonder dat het daadwerkelijk breekt. Eerst report-only draaien, letten op popup- of vensterflows die geraakt zouden worden, en pas dan overschakelen naar de afgedwongen header is het veilige pad, zeker op een site met integraties van derden die je niet zelf gebouwd hebt.",[22,63,65],{"id":64},"wat-verandert-er-op-je-site-zodra-hij-aanstaat","Wat verandert er op je site zodra hij aanstaat?",[18,67,68],{},"Voor de meeste sites niets zichtbaars. Gewone paginaladingen, navigatie en same-origin gedrag blijven onaangetast, en de isolatie gebeurt onzichtbaar op browserniveau. De winst is dat cross-origin vensters geen verwijzing naar het jouwe meer kunnen behouden, wat het aanvalsoppervlak wegneemt zonder de gebruikerservaring te raken.",[18,70,71],{},"De plek om te controleren is elke flow die bewust een andere origin opent of erdoor geopend wordt. Een betaalprovider, een identity provider, of een ingebedde tool die via vensterverwijzingen communiceert kan geraakt worden door een strikte same-origin waarde, en dat is precies waarom same-origin-allow-popups bestaat en waarom testen in report-only ertoe doet. Er is ook een voordeel dat het weten waard is: same-origin instellen, samen met de verwante Cross-Origin-Embedder-Policy header, brengt je document in een cross-origin isolated staat die sommige krachtige browserfuncties vereisen, zoals SharedArrayBuffer en timers met hoge resolutie.",[22,73,75],{"id":74},"wat-moet-je-nu-doen","Wat moet je nu doen?",[18,77,78],{},"Begin met controleren of je site überhaupt een Cross-Origin-Opener-Policy header verstuurt, want de standaard van geen header betekent geen isolatie. Als hij ontbreekt, is het risicoarme pad om hem toe te voegen in report-only modus, te bevestigen dat er niets in je popup- of externe flows breekt, en dan same-origin-allow-popups af te dwingen als verstandige standaard, of same-origin als je site geen popup-afhankelijkheden heeft.",[18,80,81,82],{},"Wil je dit correct laten controleren en instellen over je hele site in plaats van stukje bij beetje, dan kan EuroraCloud je huidige security headers bekijken en je laten zien wat ons platform oplost. ",[83,84,88],"a",{"href":85,"rel":86},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[87],"nofollow","Bekijk wat EuroraCloud oplost",[22,90,92],{"id":91},"conclusie-wat-moet-je-onthouden-over-de-cross-origin-opener-policy-header","Conclusie: wat moet je onthouden over de Cross-Origin-Opener-Policy header?",[18,94,95],{},"COOP is een stille maar waardevolle header: hij isoleert je browservenster van cross-origin pagina's en sluit daarmee een klasse van side-channel en popup-aanvallen die geen zichtbaar spoor achterlaten totdat een scanner of een aanvaller ze vindt. Voor de meeste sites is de veilige route om te testen in report-only modus en daarna same-origin-allow-popups af te dwingen, wat het venster beschermt terwijl legitieme popup-flows behouden blijven. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, is de standaard helemaal geen isolatie.",{"title":97,"searchDepth":98,"depth":98,"links":99},"",2,[100,101,102,103,104,105,106],{"id":24,"depth":98,"text":25},{"id":34,"depth":98,"text":35},{"id":44,"depth":98,"text":45},{"id":54,"depth":98,"text":55},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":91,"depth":98,"text":92},"2026-07-13","De Cross-Origin-Opener-Policy header laat een pagina zijn browservenster isoleren van cross-origin pagina's die hem openen of door hem geopend worden, waarmee een klasse van side-channel en popup-aanvallen wordt gesloten. Dit is wat de header doet, hoe je hem instelt, en wat er verandert als je dat doet.","md",[111,113,115,118,120,123,126],{"question":25,"answer":112},"COOP bestaat omdat het openen van een venster een scriptbaar verband creëert dat misbruikt kan worden. Wanneer de ene pagina de andere opent, kan de browser via window.opener een verwijzing tussen de twee vensters behouden, en als de pagina's van verschillende origins komen, wordt die verwijzing een route waarlangs een cross-origin pagina de jouwe kan aftasten via side channels en timing, een familie van technieken die bekendstaat als XS-Leaks. COOP laat een site garanderen dat zijn top-level document geen browsing context group deelt met cross-origin documenten, wat die verwijzing verbreekt.",{"question":35,"answer":114},"COOP bepaalt of je document en de pagina's waarmee het interacteert tot dezelfde browsing context group behoren, het interne browserbegrip dat bepaalt of twee vensters elkaar kunnen scripten. Strikt ingesteld gaat je venster in een eigen groep en verliezen cross-origin vensters hun verwijzing naar het jouwe. De waarden zijn unsafe-none (de standaard, geen isolatie), same-origin (strikte isolatie) en same-origin-allow-popups (isolatie die popups die je zelf opent toestaat). Onder same-origin wordt de window.opener van een cross-origin venster null.",{"question":116,"answer":117},"Wat gebeurt er als je de Cross-Origin-Opener-Policy header niet instelt?","Zonder COOP is de standaard unsafe-none, wat betekent dat er geen isolatie is en de vensterverwijzing openblijft. Een cross-origin pagina die de jouwe opent, of die jij opent, kan een greep op je venster behouden en die gebruiken als opstap voor side-channel aanvallen. Niets lijkt kapot, en juist daarom blijft het onaangepakt, maar voor een site met een login, patiëntenportaal of betaalstap is het een vermijdbare blootstelling die scanners steeds vaker aanmerken.",{"question":55,"answer":119},"Stel COOP in als één HTTP response header, op de webserver, in de applicatielaag of aan de rand. Voor de meeste sites is de juiste startwaarde same-origin-allow-popups, die isolatie geeft terwijl popup-flows behouden blijven; een site zonder popup-afhankelijkheden kan de striktere same-origin gebruiken. Test voordat je afdwingt door de report-only modus te gebruiken, verstuurd als Cross-Origin-Opener-Policy-Report-Only, die rapporteert wat de policy zou breken zonder het te breken.",{"question":121,"answer":122},"Wat verandert er op je site zodra de Cross-Origin-Opener-Policy header aanstaat?","Voor de meeste sites verandert er niets zichtbaars; gewone paginaladingen en same-origin gedrag blijven onaangetast en de isolatie gebeurt op browserniveau. De plek om te controleren is elke flow die bewust een andere origin opent of erdoor geopend wordt, zoals een betaal- of identity provider, en dat is waarom same-origin-allow-popups bestaat en waarom testen in report-only ertoe doet. same-origin instellen samen met Cross-Origin-Embedder-Policy schakelt ook een cross-origin isolated staat in die sommige krachtige functies zoals SharedArrayBuffer vereisen.",{"question":124,"answer":125},"Wat moet je nu doen met de Cross-Origin-Opener-Policy header?","Controleer of je site überhaupt een Cross-Origin-Opener-Policy header verstuurt, want geen header betekent geen isolatie. Als hij ontbreekt, voeg hem toe in report-only modus, bevestig dat er niets in je popup- of externe flows breekt, en dwing dan same-origin-allow-popups af als verstandige standaard, of same-origin als je site geen popup-afhankelijkheden heeft.",{"question":127,"answer":128},"Wat moet je onthouden over de Cross-Origin-Opener-Policy header?","COOP is een stille maar waardevolle header die je browservenster isoleert van cross-origin pagina's en daarmee een klasse van side-channel en popup-aanvallen sluit die geen zichtbaar spoor achterlaten. Voor de meeste sites is de veilige route om te testen in report-only modus en daarna same-origin-allow-popups af te dwingen, wat het venster beschermt terwijl legitieme popup-flows behouden blijven. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, is de standaard helemaal geen isolatie.",{},true,"\u002Fblog\u002Fnl\u002Fwhat-is-cross-origin-opener-policy","7 minuten",{"title":8,"description":108},"what-is-cross-origin-opener-policy","blog\u002Fnl\u002Fwhat-is-cross-origin-opener-policy",[137,4,138,139],"Cross-Origin-Opener-Policy","Webbeveiliging","Browserisolatie","M-M5zYBaNDLpkDcCmTUnLahiH8pz6DhU_huYOopU1kg",{"id":142,"title":143,"author":9,"body":144,"category":4,"date":107,"description":252,"extension":109,"faq":253,"meta":275,"navigation":130,"path":276,"readingTime":277,"seo":278,"slug":279,"stem":280,"tags":281,"__hash__":284},"blog\u002Fblog\u002Fnl\u002Fwhat-is-permissions-policy.md","Wat is de Permissions-Policy header en waarom is die belangrijk?",{"type":11,"value":145,"toc":242},[146,149,152,156,159,162,166,179,185,189,192,195,197,200,203,207,210,213,216,218,221,224,226,229,235,239],[14,147,143],{"id":148},"wat-is-de-permissions-policy-header-en-waarom-is-die-belangrijk",[18,150,151],{},"De Permissions-Policy header is een response header waarmee een website bepaalt welke browserfuncties de eigen pagina's, en alle content die daarin is ingesloten, mogen gebruiken. Functies als de camera, microfoon, locatie en betaling kunnen elk worden toegestaan, beperkt tot je eigen origin, of volledig uitgeschakeld. Hem instellen betekent dat zelfs als een script of een ingesloten derde partij een van die functies probeert te bereiken, de browser dat weigert tenzij je beleid het toestaat, wat zowel je privacyblootstelling als je aanvalsoppervlak verkleint.",[22,153,155],{"id":154},"waarom-bestaat-de-permissions-policy-header","Waarom bestaat de Permissions-Policy header?",[18,157,158],{},"Moderne browsers stellen veel krachtige mogelijkheden beschikbaar aan webpagina's: locatie, camera, microfoon, bewegingssensoren en meer. Elk script dat op je pagina draait, inclusief externe scripts die je hebt ingesloten voor analytics, chat of advertenties, kan de browser in principe vragen die mogelijkheden te gebruiken. Permissions-Policy bestaat zodat je op het niveau van de hele site kunt bepalen welke van die functies zijn toegestaan en voor wie.",[18,160,161],{},"Het doel is om het gat te dichten tussen wat een browser kan en wat je site werkelijk nodig heeft. De meeste websites gebruiken nooit de accelerometer of de payment-API, maar zonder beleid blijven die functies bereikbaar voor elke code op de pagina. Volgens de documentatie van MDN wordt de gebruiker, wanneer een beleid een functie blokkeert, niet eens om toestemming gevraagd, en mislukt de poging van een script om die te gebruiken simpelweg, wat precies de afscherming is die je wilt voor functies die je nooit van plan was te gebruiken.",[22,163,165],{"id":164},"wat-doet-de-permissions-policy-header-eigenlijk","Wat doet de Permissions-Policy header eigenlijk?",[18,167,168,169,173,174,178],{},"De header werkt als een lijst van directives, één per functie, elk met een allowlist die aangeeft welke origins hem mogen gebruiken. De syntax is de functienaam, een isgelijkteken, en de toegestane origins tussen haakjes, met meerdere directives gescheiden door komma's, bijvoorbeeld geolocation=(), camera=(self). Een lege allowlist, geschreven als (), schakelt de functie overal uit; self staat hem alleen op je eigen origin toe; een specifieke origin zoals (\"",[83,170,171],{"href":171,"rel":172},"https:\u002F\u002Fexample.com",[87],"\") staat die origin toe; en ",[175,176,177],"code",{},"*"," staat hem overal toe, inclusief ingesloten frames.",[18,180,181,182,184],{},"Een nuttig detail is dat elke functie een standaard allowlist heeft die geldt wanneer je niets opgeeft, en afhankelijk van de functie is die standaard ",[175,183,177],{},", self, of geen. De waarde van het expliciet instellen van de header is dus dat je niet langer op de standaarden per functie leunt, maar een bewuste, uniforme keuze maakt: zet alles uit wat je niet gebruikt, en beperk alles wat je wel gebruikt tot je eigen origin of de specifieke partners die het nodig hebben.",[22,186,188],{"id":187},"hoe-gedraagt-de-header-zich-met-ingesloten-iframes","Hoe gedraagt de header zich met ingesloten iframes?",[18,190,191],{},"Dit is het deel waar de meeste mensen over struikelen, dus het is de moeite waard om precies te zijn. Een functie is alleen beschikbaar binnen een ingesloten iframe als aan twee voorwaarden tegelijk wordt voldaan: je top-level pagina moet de functie in zijn Permissions-Policy toestaan voor de origin van dat frame, en het iframe zelf mag hem niet hebben uitgeschakeld. Met andere woorden: de bovenliggende pagina stelt de buitengrens in, en niets wat is ingesloten kan zichzelf een functie toekennen die de bovenliggende pagina heeft onthouden.",[18,193,194],{},"Er is ook een besturing per iframe die naast de header werkt, het allow-attribuut op het iframe-element, bijvoorbeeld een ingesloten kaart toegevoegd met een frame waarvan het allow-attribuut geolocation toestaat. Het mentale model om vast te houden is dat de header het sitebrede beleid is en het allow-attribuut de uitzondering per insluiting daarbinnen: het frame kan alleen ontvangen wat de header al toestaat, en het attribuut verfijnt of richt dat vervolgens op die specifieke insluiting. Dit is precies waarom een externe widget soms meldt dat een functie is geblokkeerd terwijl de code van de widget correct is, omdat de omliggende pagina die functie nooit voor de origin van de widget heeft toegestaan.",[22,196,45],{"id":44},[18,198,199],{},"Zonder de header valt elke functie terug op zijn eigen standaard allowlist, die voor verschillende functies ruimer is dan een typische site nodig heeft. In de praktijk betekent dat dat mogelijkheden die je nooit gebruikt bereikbaar blijven, en dat ingesloten externe content functies kan aanvragen die je niet zou hebben toegekend als je het gevraagd was.",[18,201,202],{},"Dit is meestal geen urgent gat, en juist daarom blijft het onaangepakt, maar het is wel een reëel gat. Het weegt het zwaarst waar je code insluit die je niet zelf hebt geschreven: een analytics-tag, een chatwidget, een marketingpixel. Het beperken van functies die je niet gebruikt verkleint wat al die ingesloten code kan proberen, en het is precies het soort ontbrekende header dat securityscanners en audits inmiddels op vrijwel elke site aanmerken die hem niet heeft ingesteld.",[22,204,206],{"id":205},"hoe-implementeer-je-de-permissions-policy-header","Hoe implementeer je de Permissions-Policy header?",[18,208,209],{},"Je stelt Permissions-Policy in als één HTTP response header. Een verstandig startbeleid is om de functies uit te schakelen waarvan je weet dat je ze niet gebruikt en de rest tot je eigen origin te beperken, bijvoorbeeld Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), en dan alleen individuele directives te versoepelen waar een echte behoefte bestaat. Hij kan worden toegepast op de webserver, in de applicatielaag, of aan de rand in een CDN of securitylaag voor de site.",[18,211,212],{},"Het helpt om dit tegen een echte site te bekijken in plaats van in abstracte termen. Neem een kliniekwebsite die een ingesloten kaart toont zodat patiënten de praktijk kunnen vinden, en een online boekingstool draait die een betaalstap opent, maar verder geen browserfuncties gebruikt. Een beleid dat op die site is afgestemd zou alles uitschakelen wat hij nooit aanraakt en alleen toestaan wat die twee functies nodig hebben: geolocation beperkt tot de origin van de kaartprovider, payment beperkt tot de boekings- of betaalprovider, en camera, microfoon en de diverse sensorfuncties allemaal uitgezet met een lege allowlist. Het resultaat is een pagina waar de kaart en de checkout precies werken als voorheen, terwijl elke andere mogelijkheid simpelweg niet beschikbaar is voor welk script dan ook, of dat script nu van jou is of van een ingesloten derde partij. Het principe is algemeen toepasbaar: benoem wat de site echt gebruikt, sta die toe aan de specifieke origins die ze leveren, en sluit de rest af.",[18,214,215],{},"Test voordat je hem vastzet. De header heeft een report-only tegenhanger, Permissions-Policy-Report-Only, die de Reporting API van de browser gebruikt om je te vertellen wat een beleid zou blokkeren zonder het daadwerkelijk af te dwingen. Die eerst draaien is de veilige manier om te ontdekken of een echte functie, een kaart die geolocation nodig heeft, een boekingstool die een betaalflow opent, een ingesloten video, door je beleid zou worden gevangen, zodat je die bewust toestaat in plaats van hem per ongeluk te breken.",[22,217,65],{"id":64},[18,219,220],{},"Voor de meeste sites niets zichtbaars. Gewone pagina's die geen beperkte functies gebruiken gedragen zich precies als voorheen, en bezoekers merken niets, omdat het beleid alleen ingrijpt wanneer een stuk code een functie probeert te bereiken die je niet hebt toegestaan.",[18,222,223],{},"De plek om te controleren is elke functie waar je eigen site echt op leunt, en alles wat je ingesloten derde partijen nodig hebben. Een winkelzoeker die geolocation gebruikt, een videobelfunctie die camera en microfoon gebruikt, of een checkout die de payment-API gebruikt, moeten allemaal hun directives zo hebben ingesteld dat de juiste origins worden toegestaan, en dat is precies waarom testen in report-only ertoe doet voordat je afdwingt. Krijg dat één keer goed en de header houdt daarna stilletjes de lijn vast, staat toe wat je bedoelde en weigert al het andere.",[22,225,75],{"id":74},[18,227,228],{},"Begin met controleren of je site überhaupt een Permissions-Policy header verstuurt, want zonder een header valt elke functie simpelweg terug op zijn standaard. Als hij ontbreekt, is het risicoarme pad om hem toe te voegen in report-only modus, de functies op te sommen die je daadwerkelijk gebruikt, te bevestigen dat niets waar je op leunt wordt geblokkeerd, en dan een beleid af te dwingen dat al het andere uitschakelt.",[18,230,81,231],{},[83,232,88],{"href":233,"rel":234},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[87],[22,236,238],{"id":237},"conclusie-wat-moet-je-onthouden-over-de-permissions-policy-header","Conclusie: wat moet je onthouden over de Permissions-Policy header?",[18,240,241],{},"Permissions-Policy is een stille, praktische header: hij laat je de browserfuncties uitschakelen die je site nooit gebruikt en de functies die hij wel gebruikt beperken tot alleen de origins die ze nodig hebben, zodat noch je eigen scripts noch ingesloten derde partijen mogelijkheden kunnen bereiken die je nooit van plan was bloot te stellen. De veilige manier om hem in te voeren is testen in report-only modus, bevestigen dat je echte functies nog werken, en dan een beleid afdwingen dat de rest uitschakelt. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, staat elke functie op zijn standaard.",{"title":97,"searchDepth":98,"depth":98,"links":243},[244,245,246,247,248,249,250,251],{"id":154,"depth":98,"text":155},{"id":164,"depth":98,"text":165},{"id":187,"depth":98,"text":188},{"id":44,"depth":98,"text":45},{"id":205,"depth":98,"text":206},{"id":64,"depth":98,"text":65},{"id":74,"depth":98,"text":75},{"id":237,"depth":98,"text":238},"Met de Permissions-Policy header bepaal je welke browserfuncties, zoals camera, microfoon en locatie, je eigen pagina's en ingesloten content mogen gebruiken. Dit is wat de header doet, hoe je hem instelt, en wat er verandert als je dat doet.",[254,256,258,261,264,266,269,272],{"question":155,"answer":255},"Moderne browsers stellen krachtige mogelijkheden beschikbaar zoals locatie, camera, microfoon en bewegingssensoren, en elk script op je pagina, inclusief ingesloten externe code, kan in principe vragen die te gebruiken. Permissions-Policy bestaat zodat je op siteniveau kunt bepalen welke functies zijn toegestaan en voor wie, en zo het gat dicht tussen wat een browser kan en wat je site echt nodig heeft. Wanneer een beleid een functie blokkeert, wordt de gebruiker niet eens gevraagd en mislukt de poging van een script simpelweg.",{"question":165,"answer":257},"De header is een lijst van directives, één per functie, elk met een allowlist van origins die hem mogen gebruiken. De syntax is de functienaam, een isgelijkteken, en de toegestane origins tussen haakjes, met directives gescheiden door komma's, bijvoorbeeld geolocation=(), camera=(self). Een lege allowlist () schakelt de functie overal uit, self staat alleen je eigen origin toe, een specifieke origin staat die origin toe, en * staat hem overal toe. Elke functie heeft ook een standaard allowlist van *, self of geen die geldt wanneer je niets opgeeft.",{"question":259,"answer":260},"Hoe gedraagt de Permissions-Policy header zich met ingesloten iframes?","Een functie is alleen beschikbaar binnen een ingesloten iframe als aan twee voorwaarden tegelijk wordt voldaan: je top-level pagina moet de functie toestaan voor de origin van dat frame, en het iframe zelf mag hem niet hebben uitgeschakeld. De bovenliggende pagina stelt de buitengrens in en niets wat is ingesloten kan zichzelf een functie toekennen die de bovenliggende pagina heeft onthouden. Het allow-attribuut op het iframe-element werkt daarnaast als uitzondering per insluiting: het frame kan alleen ontvangen wat de header al toestaat.",{"question":262,"answer":263},"Wat gebeurt er als je de Permissions-Policy header niet instelt?","Zonder de header valt elke functie terug op zijn eigen standaard allowlist, die voor verschillende functies ruimer is dan een typische site nodig heeft. Mogelijkheden die je nooit gebruikt blijven bereikbaar, en ingesloten externe content kan functies aanvragen die je niet zou hebben toegekend. Het is zelden urgent, en daarom blijft het onaangepakt, maar het weegt het zwaarst waar je code insluit die je niet zelf schreef, zoals een analytics-tag, chatwidget of marketingpixel, en scanners merken het inmiddels op vrijwel elke site aan die hem niet heeft ingesteld.",{"question":206,"answer":265},"Stel Permissions-Policy in als één HTTP response header, op de webserver, in de applicatielaag of aan de rand. Een verstandig startbeleid schakelt functies uit die je niet gebruikt en beperkt de rest tot je eigen origin, bijvoorbeeld geolocation=(), camera=(), microphone=(), payment=(). Test eerst met de report-only tegenhanger, Permissions-Policy-Report-Only, die de Reporting API van de browser gebruikt om te vertellen wat een beleid zou blokkeren zonder het af te dwingen, zodat je echte functies bewust toestaat in plaats van ze per ongeluk te breken.",{"question":267,"answer":268},"Wat verandert er op je site zodra de Permissions-Policy header aanstaat?","Voor de meeste sites verandert er niets zichtbaars, omdat het beleid alleen ingrijpt wanneer code een functie probeert te bereiken die je niet hebt toegestaan. De plek om te controleren is elke functie waar je eigen site op leunt en alles wat je ingesloten derde partijen nodig hebben, zoals een winkelzoeker met geolocation, een videofunctie met camera en microfoon, of een checkout met de payment-API, die allemaal hun directives zo moeten hebben ingesteld dat de juiste origins worden toegestaan. Daarom doet testen in report-only ertoe voordat je afdwingt.",{"question":270,"answer":271},"Wat moet je nu doen met de Permissions-Policy header?","Controleer of je site überhaupt een Permissions-Policy header verstuurt, want zonder een header valt elke functie terug op zijn standaard. Als hij ontbreekt, voeg hem toe in report-only modus, som de functies op die je daadwerkelijk gebruikt, bevestig dat niets waar je op leunt wordt geblokkeerd, en dwing dan een beleid af dat al het andere uitschakelt.",{"question":273,"answer":274},"Wat moet je onthouden over de Permissions-Policy header?","Permissions-Policy laat je de browserfuncties uitschakelen die je site nooit gebruikt en de functies die hij wel gebruikt beperken tot alleen de origins die ze nodig hebben, zodat noch je eigen scripts noch ingesloten derde partijen mogelijkheden kunnen bereiken die je nooit wilde blootstellen. De veilige manier om hem in te voeren is testen in report-only modus, bevestigen dat je echte functies nog werken, en dan een beleid afdwingen dat de rest uitschakelt. De nuttigste stap is controleren of je site de header vandaag verstuurt, want zolang dat niet zo is, staat elke functie op zijn standaard.",{},"\u002Fblog\u002Fnl\u002Fwhat-is-permissions-policy","8 minuten",{"title":143,"description":252},"what-is-permissions-policy","blog\u002Fnl\u002Fwhat-is-permissions-policy",[282,4,138,283],"Permissions-Policy","Privacy","HA0UjuttZdPkXfGe014PR-rVNqdxHSkoeDnA4gJrgiY",1785141129975]