Onze WordPress-CSP: strict-dynamic en nonces voor styles

Bijgewerkt en productieheader gecontroleerd op 17 september 2026. Deze versie vervangt de eerdere uitleg over Cookiebot en inline styles. De configuratie hieronder is een momentopname van de publieke website, geen universeel recept voor iedere WordPress-installatie.

Wat er nu anders is

• script-src gebruikt een nonce met 'strict-dynamic', zonder 'unsafe-inline' of 'unsafe-eval'.
• Ook style-src gebruikt nu een nonce. style-src-attr 'none' blokkeert inline style-attributen.
• base-uri 'none' staat geen alternatieve basis-URL toe. form-action 'self' beperkt formulierbestemmingen tot dezelfde origin.
• De cookiebanner is Complianz, niet meer Cookiebot. In de gemeten CSP staan nog wel oude Cookiebot-domeinen; een vermelding in de allowlist bewijst niet dat een dienst actief wordt gebruikt.

De kern van onze productie-CSP

Een Content-Security-Policy vertelt de browser welke bronnen en uitvoeringsvormen zijn toegestaan. Dit zijn geselecteerde directives uit de gemeten productieheader. De nonce is hieronder vervangen door een beschrijvende waarde. De bronlijsten voor afbeeldingen, verbindingen, fonts en frames en de rapportage-instellingen zijn weggelaten: dit fragment is dus geen complete configuratie om over te nemen.

default-src 'self';
base-uri 'none';
object-src 'none';
upgrade-insecure-requests;
script-src 'nonce-PER_RESPONSE_RANDOM_VALUE' 'strict-dynamic';
style-src 'self' 'nonce-PER_RESPONSE_RANDOM_VALUE' https://use.typekit.net https://p.typekit.net https://fonts.googleapis.com https://www.gstatic.com;
style-src-attr 'none';
media-src 'self';
form-action 'self';
frame-ancestors 'self';
worker-src 'self' blob:;

default-src is een terugvalregel voor resource-types zonder eigen directive. base-uri 'none' voorkomt dat een <base>-element de basis voor relatieve URL’s verandert. object-src 'none' blokkeert object- en embed-resources. frame-ancestors 'self' beperkt welke pagina’s onze website mogen insluiten; frame-src bepaalt juist welke frames onze eigen pagina mag laden.

form-action 'self' gaat over formulierverzendingen, niet over alle mogelijke data-uitwisseling. JavaScript-verzoeken vallen bijvoorbeeld onder connect-src. Een formulier dat rechtstreeks naar een externe dienst post, vraagt daarom om een aparte beoordeling. Een CSP is geen algemene garantie dat gegevens de website niet kunnen verlaten.

Scripts: vertrouwen begint bij een nonce

Een nonce is een onvoorspelbare waarde die in de CSP-header en op de bedoelde script-elementen overeenkomt. Met 'strict-dynamic' kunnen vertrouwde scripts vervolgens andere scripts programmatisch laden. Daardoor is voor die scriptketen geen lijst van ieder leveranciersdomein nodig. Dat vertrouwen heeft wel gevolgen: ook een tagmanager moet zorgvuldig worden beheerd. De overige directives, zoals connect-src en img-src, blijven afzonderlijk gelden.

Geef alleen vertrouwde uitvoer een nonce. Achteraf ieder aangetroffen script automatisch een nonce geven, maakt op zichzelf geen onderscheid tussen bedoelde code en geinjecteerde code. Veilige templates, invoercontrole en correcte escaping blijven nodig. Een strikte header vervangt die maatregelen niet.

Een nonce maakt eval() of new Function() niet toegestaan. Plugins of optimalisaties die daarvan afhankelijk zijn, moeten worden aangepast, anders ingesteld of vervangen om zonder 'unsafe-eval' te werken. Alleen een ruime permissie verwijderen en de homepage openen is geen volledige compatibiliteitstest. Zie ook de documentatie over script-src.

Styles: unsafe-inline is geen noodzakelijk restant

De eerdere versie van dit artikel stelde dat inline styles in WordPress niet realistisch te verwijderen waren en dat het beveiligingseffect verwaarloosbaar was. Dat was te absoluut. Onze actuele header laat stylesheets van de genoemde bronnen toe en gebruikt nonces voor <style>-elementen. 'unsafe-inline' staat er niet meer in.

Een nonce op een style-element geeft geen toestemming aan style="..." op een ander HTML-element. Die attributen worden door style-src-attr 'none' geblokkeerd. Gebruik waar mogelijk CSS-klassen en externe stylesheets. Test ook dynamische onderdelen zoals sliders, formulieren en de editor: verschillende manieren waarop JavaScript styling aanpast, worden niet identiek door CSP behandeld. De documentatie over style-src-attr licht dat onderscheid toe.

Caching mag nonces niet vastzetten

Bij full-page caching kunnen dezelfde HTML-bytes aan meerdere bezoekers worden geleverd. Een daarin opgeslagen nonce mag niet simpelweg samen met de header worden hergebruikt. In onze opzet gebruikt gecachte HTML een tijdelijke markering die de webserver bij het uitleveren vervangt; de header moet exact dezelfde nieuwe waarde krijgen. Die vervanging hoort na de gedeelde page-cache plaats te vinden.

Controleer daarom meerdere responses, zowel met koude als warme cache: wisselt de nonce, komt hij overeen tussen header en HTML en blijft nergens een tijdelijke markering staan? Na een wijziging moet ook oude page-cache worden verwijderd. Anders kan een bijgewerkte release nog HTML met verouderde scripts of instellingen uitleveren.

Complianz en externe diensten apart testen

Complianz verzorgt nu de cookiebanner. CSP en cookietoestemming hebben verschillende taken: toestemming bepaalt of een dienst mag worden geactiveerd, CSP begrenst wat de browser technisch mag laden of uitvoeren. Het ene mechanisme vervangt het andere niet.

De huidige bronlijsten bevatten nog Cookiebot-verwijzingen. Daarom noemen we deze policy niet de kleinst mogelijke configuratie. Oude uitzonderingen vragen om onderzoek en gecontroleerde verwijdering, niet om de aanname dat iedere vermelding nog noodzakelijk is. Hetzelfde geldt voor blob: bij frames en workers: bepaal per toepassing of dit nodig is; niet iedere WordPress-editor vereist dezelfde uitzonderingen.

Wat een controle wel en niet bewijst

Voor aanscherpingen kan een aanvullende Content-Security-Policy-Report-Only-header helpen om mogelijke blokkades te onderzoeken. Die beleidstekst blokkeert zelf niets en rapportage is niet volledig. Houd een bestaande afdwingende policy dus actief. Combineer rapporten met browserconsole, netwerkverzoeken en echte gebruikershandelingen.

• Test belangrijke paginatypen op mobiel en desktop, inclusief formulieren, navigatie, afbeeldingen en video.
• Controleer de cookiebanner voor accepteren, weigeren, intrekken en een volgend bezoek.
• Neem login, editor, previews en beheerschermen mee; een werkende voorkant bewijst niet dat de backend werkt.
• Controleer fouten na updates opnieuw. Een schoon rapport over een bepaalde testperiode is geen garantie voor alle routes en bezoekers.

Een goede Internet.nl-score gaat over de standaarden die die meting test, niet over de volledige veiligheid van WordPress. Ook HSTS is een afzonderlijke header, geen CSP-directive. De aanwezigheid van preload in HSTS bewijst op zichzelf niet dat een domein in de preloadlijst van browsers is opgenomen. Claims over scores, foutloosheid en ondersteuning moeten daarom altijd een meetdatum en duidelijke scope hebben.

Beheer hoort bij de oplossing

Bij Cobytes wordt de webserverconfiguratie via Git en de reguliere Ansible-route beheerd. Websitewijzigingen gaan via acceptance voordat ze naar productie worden gepromoveerd. De header en de HTML die WordPress levert moeten bij elkaar blijven passen; alleen een header in nginx zetten is niet voldoende.

Wil je weten hoe dit past bij jouw website? Bekijk managed hosting en security van Cobytes. Meer achtergrond vind je in ons artikel over security headers en website-hardening in de praktijk. Welke maatregelen passend zijn, hangt af van de applicatie en de afgesproken beheeromvang.