Risico's toevoegen van 'unsafe-eval' header

Doorgaan met de discussie van Gegroet!:

Ha community,

Tijdens het gebruik van AlpineJS lopen we er tegenaan dat als we alle functionaliteit van het framework willen gebruiken we de “unsafe-eval” aan onze headers toe moeten voegen.

Een link naar de demo omgeving van onze branch kan je hier vinden: https://don-review-alpinejs-r-6yf60q.nlx.reviews/apis

De vraag aan jullie: komen we in de clinch met audits, en hoe onveilig is het toevoegen van een “unsafe-eval” header?

Het gebruik eval functionaliteit is een risico dat zeer moeilijk te mitigeren valt. Dat is ook de reden van eigenlijke CSP header check het gebruik van unsafe-eval als een failure ziet.
De risico’s die ontstaan door het gebruik van unsafe-eval zijn eigenlijk van dien aard dat alle andere CSP headers bijna niet meer van toegevoegde waarde zijn zodra er een XSS gevonden is in die applicatie, of in Alpine zelf.
De beschikbaarheid van honderden frameworks die zonder eval werken zou daarnaast voldoende ‘food for thought’ moeten opleveren of Alpine en de onwil/onmogelijkheid om daar binnen zonder eval te kunnen werken nog wel een redelijke optie is voor frontend development. Er is daarnaast een altenatieve build van Alipe die zonder Eval werkt, er is dan wel subtiel andere code nodig omdat de strings niet meer direct als code kunnen worden gevalueerd. Dit laatste is immers precies waarom Eval en varianten zo gevaarlijk is.
https://alpinejs.dev/advanced/csp

Voor wat betreft je vraag over Audits, een DigiD assesment zou je met unsafe-eval niet moeten kunnen doorstaan, en dit geldt ook voor legio andere pentests en security of kwaliteit-tests.

De risico’s die aa unsafe-eval verbonden zijn gelden in zekere zin trouwens ook voor bepaalde domeinen in de allow-list. Immers als iedereen een pakket kan hosten op een geallowed domein dan kan met een XSS deze code dus via die domein in de content van jouw site worden uitgevoerd. Voorbeelden van dit soort domeinen zijn bijvoorbeeld
jsdelivr, githubpages, cdn.skypack.dev
Maar ook url-shorteners vallen hier onder.

Ha Jan! Bedankt voor je uitgebreide antwoord.

Ik begrijp dat Alpine niet volledig werkt als we de CSP header blijven behouden. Maar de CSP header is nodig om compliant te zijn. Ik kan dus niet anders dan meegaan met je punt dat je dus je vraagtekens zou moeten zetten bij het gebruik van Alpine.

Er is inderdaad een CSP build maar het is volgens mij best pittig om dit zelf te builden. Getuige deze thread.