Je suis un fervent utilisateur de Grist depuis près de 18 mois et je vois avec joie le virus se répandre dans mon administration. Je constate également depuis quelques mois de nouveaux usages notamment portés par l’apparition de nouveaux widgets.
Malgré tout l’amour que je porte à Grist, je suis préoccupé par le risque apporté par le combo multiplication des utilisateurs x multiplication des custom widgets. Je sens qu’avec la multiplication des usages, de nombreux risques pour la sécurité risques d’apparaitre.
De nombreux utilisateurs de Grist ne sont ni développeurs ni spécialistes RGPD, aussi je ne serai pas surpris qu’un mauvais usage de Grist et en particulier des widget aboutisse à des fuites de données sensibles. Aussi je perçois deux profils d’utilisateurs : ceux qui n’utilisent que les widget « officiels » (ou qui savent développer et créer des widget « safe ») et ceux qui utilisent les widgets trouvés sur internet sans mesurer les risques associés.
Ma question (plutôt adressée à la DINUM) : avez-vous une stratégie concernant l’usage des widgets ? Prévoyez vous d’auditer les widget avec le plus gros potentiel ? Estimez-vous qu’il y existe aujourd’hui un risque concernant un usage massif des widget personnalisés ?
Encore merci à tout ceux qui s’impliquent dans ce bel outil !
Merci pour cette question très pertinente !
La sécurité des widgets personnalisés est effectivement un sujet crucial, surtout avec l’adoption croissante de Grist dans les administrations.
Je partage tes préoccupations et c’est justement pour y répondre que j’ai développé GristUp , un catalogue de widgets Grist avec un système d’analyse de sécurité intégré .
Ce que nous vérifions avant d’approuver un widget
Chaque widget soumis au catalogue est analysé automatiquement pour détecter :
Catégorie
Vérifications
Injection de code
eval() , new Function() , document.write()
XSS
innerHTML , scripts non sécurisés
Vol de données
Accès cookies, localStorage, clipboard
Keylogger
Écoute des frappes clavier
Exfiltration
sendBeacon() , pixels espions
Obfuscation
Code encodé en base64, hex, unicode
Permissions sensibles
Géolocalisation, caméra, micro
Crypto-mining
Coinhive, CryptoNight
Prototype pollution
Manipulation de __proto__
Chaque widget reçoit un indice de confiance (0-100%) et seuls les widgets jugés sûrs sont publiés dans le catalogue.
Bonjour,
Merci pour votre contribution. Votre outil d’audit est-il mutualisé ? Je développe des customs widgets en vibe coding, j’essaie de faire attention à la sécurité, mais s’il existe un outil supplémentaire pour tester la sécurité de mes widgets, ça m’intéresse.
Pour information, je m’appuie actuellement sur :
Un pré-prompt intégrant des consignes relatives à la sécurité ;
Des plugins de contrôle, dans VS Code ;
Des audits spécifiques du code par l’IA avec un prompt ciblé « Sécurité applicative (OWASP) ».
Le scanner analyse automatiquement le code HTML et JavaScript d’un widget et détecte :
Injection de code (eval, new Function…)
XSS (innerHTML, document.write…)
Vol de données (cookies, clipboard…)
Keylogger / Capture (événements clavier)
Exfiltration (sendBeacon, tracking pixels…)
Scripts externes (CDN, API tierces…)
Et bien d’autres patterns suspects
La sécurité à 100% n’existe pas. Ce scanner automatisé détecte les patterns de code suspects les plus courants, mais ne peut pas garantir l’absence totale de vulnérabilités.
En cas de doute sur un widget, nous recommandons d’examiner manuellement le code source avant utilisation. Un score élevé est un bon indicateur, mais ne remplace pas une revue humaine pour les cas sensibles.
Ça y est, ça fonctionne, merci. J’avais essayé avec différents navigateurs, il fallait peut-être un peu de temps pour que le changement soit fonctionnel. Des fois, il ne faut pas être trop pressé
Bonne journée !
Oui, il existe des risques majeurs à l’utilisation de widgets personnalisés (widgets intégrés via le « Custom url » ou via le « Custom Widget Builder ») : code malveillant ou failles de sécurité. Nous observons par ailleurs que nombre de ces widgets sont créés avec l’IA, et que le code n’est pas toujours maîtrisé, ce qui est encore plus dangereux.
Pour les instances DINUM et ANCT, le positionnement est très clair :
Nous recommandons uniquement l’utilisation des widgets présents dans la bibliothèque de widgets personnalisés
Nous allons faire une sélection de plusieurs widgets, ceux que nous jugeons les plus utiles
Nous allons auditer cette séléction de widgets - et seuls ceux dignes de confiance après audit, et maintenables seront ajoutés à nos instances (par exemple, les custom widgets dont le vibecode a produit du code illisible par les humains ne seront pas retenus)
Nous allons proposer un guide de contribution, pour donner des lignes directrices pour le développement des custom widgets - pour qu’ils soient potentiellement intégrables aux instances de l’Etat
Nous allons ajouter un bandeau préventif à tous les posts forum présentant des widgets personnalisés. Nous mettrons aussi en place de la sensibilisation sur nos canaux internes.
Merci beaucoup pour cette réponse très claire et pleine de bon sens. J’ai hâte de voir de nouveaux widgets intégrés à la bibliothèque.
Au passage, lorsque l’on créé un espace « équipe » ne pourrait-t-on pas avoir un paramètre interdisant l’utilisation de widget hors bibliothèque (ou basée sur des autorisations document par document) ? Cela permettrai aux administrateurs de mieux savoir quels sont les documents à risque.
bonjour et merci de mettre à disposition ce canal d’audit et de partage.
est-ce que vous pourriez ajouter un copier-coller du rapport d’audit ou extraction PDF pour pouvoir partager le rapport ou le faire corriger par l’IA ? (sinon le copier via la sélection en faisant défiler fonctionne)
Bonjour, peut-on suggérer l’audit de certains widgets, afin qu’ils puissent intégrer la bibliothèque officielle ? Je pense en particulier à ce widget, qui est bigrement intéressant et permet de débloquer tout un univers de possibles en termes de gestion de données géolocalisées : https://forum.grist.libre.sh/t/de-qgis-a-grist-en-2-clics/3065