[{"data":1,"prerenderedAt":171},["ShallowReactive",2],{"blog-tag-nl-privacy":3},{"tagName":4,"posts":5},"Privacy",[6],{"id":7,"title":8,"author":9,"body":10,"category":134,"date":135,"description":136,"extension":137,"faq":138,"meta":160,"navigation":161,"path":162,"readingTime":163,"seo":164,"slug":165,"stem":166,"tags":167,"__hash__":170},"blog\u002Fblog\u002Fnl\u002Fwhat-is-permissions-policy.md","Wat is de Permissions-Policy header en waarom is die belangrijk?","EuroraCloud Team",{"type":11,"value":12,"toc":122},"minimark",[13,17,21,26,29,32,36,51,57,61,64,67,71,74,77,81,84,87,90,94,97,100,104,107,115,119],[14,15,8],"h1",{"id":16},"wat-is-de-permissions-policy-header-en-waarom-is-die-belangrijk",[18,19,20],"p",{},"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,23,25],"h2",{"id":24},"waarom-bestaat-de-permissions-policy-header","Waarom bestaat de Permissions-Policy header?",[18,27,28],{},"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,30,31],{},"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,33,35],{"id":34},"wat-doet-de-permissions-policy-header-eigenlijk","Wat doet de Permissions-Policy header eigenlijk?",[18,37,38,39,45,46,50],{},"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 (\"",[40,41,42],"a",{"href":42,"rel":43},"https:\u002F\u002Fexample.com",[44],"nofollow","\") staat die origin toe; en ",[47,48,49],"code",{},"*"," staat hem overal toe, inclusief ingesloten frames.",[18,52,53,54,56],{},"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 ",[47,55,49],{},", 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,58,60],{"id":59},"hoe-gedraagt-de-header-zich-met-ingesloten-iframes","Hoe gedraagt de header zich met ingesloten iframes?",[18,62,63],{},"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,65,66],{},"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,68,70],{"id":69},"wat-gebeurt-er-als-je-hem-niet-instelt","Wat gebeurt er als je hem niet instelt?",[18,72,73],{},"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,75,76],{},"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,78,80],{"id":79},"hoe-implementeer-je-de-permissions-policy-header","Hoe implementeer je de Permissions-Policy header?",[18,82,83],{},"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,85,86],{},"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,88,89],{},"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,91,93],{"id":92},"wat-verandert-er-op-je-site-zodra-hij-aanstaat","Wat verandert er op je site zodra hij aanstaat?",[18,95,96],{},"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,98,99],{},"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,101,103],{"id":102},"wat-moet-je-nu-doen","Wat moet je nu doen?",[18,105,106],{},"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,108,109,110],{},"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. ",[40,111,114],{"href":112,"rel":113},"https:\u002F\u002Fwww.euroracloud.eu\u002F",[44],"Bekijk wat EuroraCloud oplost",[22,116,118],{"id":117},"conclusie-wat-moet-je-onthouden-over-de-permissions-policy-header","Conclusie: wat moet je onthouden over de Permissions-Policy header?",[18,120,121],{},"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":123,"searchDepth":124,"depth":124,"links":125},"",2,[126,127,128,129,130,131,132,133],{"id":24,"depth":124,"text":25},{"id":34,"depth":124,"text":35},{"id":59,"depth":124,"text":60},{"id":69,"depth":124,"text":70},{"id":79,"depth":124,"text":80},{"id":92,"depth":124,"text":93},{"id":102,"depth":124,"text":103},{"id":117,"depth":124,"text":118},"Security Headers","2026-07-13","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.","md",[139,141,143,146,149,151,154,157],{"question":25,"answer":140},"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":35,"answer":142},"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":144,"answer":145},"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":147,"answer":148},"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":80,"answer":150},"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":152,"answer":153},"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":155,"answer":156},"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":158,"answer":159},"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.",{},true,"\u002Fblog\u002Fnl\u002Fwhat-is-permissions-policy","8 minuten",{"title":8,"description":136},"what-is-permissions-policy","blog\u002Fnl\u002Fwhat-is-permissions-policy",[168,134,169,4],"Permissions-Policy","Webbeveiliging","HA0UjuttZdPkXfGe014PR-rVNqdxHSkoeDnA4gJrgiY",1785141130317]