Contrôler les erreurs CSP avec un fetch() personnalisé
Pourquoi ça compte pour toi
Si tu développes une app web complexe avec des restrictions de sécurité strictes (CSP), tu sais qu'ajouter un nouveau domaine signifie redéployer. Là, tu peux offrir une expérience fluide : l'app détecte elle-même ce qui bloque, le demande à l'utilisateur, et recharge sans intervention backend. C'est particulièrement utile pour les iframes sandbox sécurisées.
Ce qu'il faut retenir
- 1.Une iframe en sandbox CSP peut charger une app avec un fetch() personnalisé qui capture les erreurs
- 2.Ces erreurs remontent à la fenêtre parente via postMessage ou événement custom
- 3.L'utilisateur peut créer une liste d'autorisation dynamique sans redéployer l'app
- 4.L'expérience qui en résulte est plus fluide qu'une gestion statique des domaines
Tu galères avec le jargon ?
Lis la version réécrite en mode débutant — toutes les idées, sans le jargon.
Pourquoi c'est pertinent
Les Content Security Policy (CSP) sont essentielles pour protéger une app web contre les injections et les attaques XSS. Mais elles peuvent être rigides : dès qu'une ressource (image, script, font) vient d'un domaine non autorisé, ça bloque.
Traditionnellement, tu dois :
- ▸Identifier le domaine manquant
- ▸L'ajouter à la CSP
- ▸Redéployer
- ▸Recharger la page
L'expérience utilisateur est médiocre.
La solution : interception + liste d'autorisation dynamique
Cette expérimentation de Simon Willison (avec GPT-5.5 dans Codex) démontre une approche différente :
- ▸L'app tourne dans une iframe sandboxée avec CSP active
- ▸Un fetch() personnalisé attrape toutes les requêtes bloquées par la CSP
- ▸Au lieu d'échouer silencieusement, il remonte l'erreur à la fenêtre parente
- ▸La fenêtre parente propose à l'utilisateur d'ajouter le domaine à une liste d'autorisation
- ▸Un rechargement simple (de la page ou juste de la ressource) suffit
Cas d'usage concrets
Pour une app SaaS : tu déploies une app complexe avec intégrations tierces. Quand un client branche une nouvelle API, l'app le détecte et demande : « Autoriser example.com ? ». Pas besoin de ticket support.
Pour un tableau de bord d'analyse : si l'utilisateur charge un graphique depuis un nouveau service, l'app gère ça toute seule.
Pour une place de marché : les vendeurs intègrent leurs propres widgets. L'app valide et autorise via la CSP sans intervention.
Points techniques clés
- ▸Le postMessage ou les événements custom entre iframe et parent font la liaison
- ▸La liste d'autorisation peut être stockée localement (localStorage) ou en base
- ▸Chaque autorisation est validée par l'utilisateur, pas automatique
- ▸La CSP reste active et protectrice, simplement plus flexible
Le bémol
C'est une expérimentation. En l'état, c'est une preuve de concept. Avant de passer en production, tu dois :
- ▸Valider la sécurité (une liste d'autorisation mal gérée peut réduire à néant la CSP)
- ▸Tester les cas limites (redirections, domaines changeants, etc.)
- ▸Décider du périmètre : qui peut alimenter la liste d'autorisation ?
Et concrètement pour toi ?
Choisis ton profil — la lecture de l'article change selon qui tu es.
Pour toi, retiens que la sécurité web n'est plus juste du statique : les apps modernes permettent aux utilisateurs de décider eux-mêmes ce qui est safe. C'est un shift philosophique : moins de gatekeeping technique, plus de responsabilité partagée.
Essayer maintenant
→Source
Pour aller plus loin
Cet article t'a donné envie d'approfondir ? Deux formations Noésis t'attendent :
Explorer les thèmes de cet article :