Sécurité

Notre modèle de sécurité en une phrase : il n'y a rien sur un serveur à attaquer. Tout ce qui suit est vérifiable depuis vos DevTools.

Architecture

Le générateur est une application monopage statique servie depuis Cloudflare Pages : pas de comptes utilisateur, pas d'authentification, et aucun chemin de code backend nulle part dans le flux de génération. Chaque opération de génération, d'encodage, de scan et de rendu de QR s'exécute entièrement dans votre navigateur. Un petit point de terminaison serverless se trouve à côté et est listé ici plutôt que caché : /api/contact (le formulaire de contact, qui stocke ce que vous soumettez dans Cloudflare D1 et nous l'envoie par e-mail). Il n'est pas appelé lorsque vous créez un code QR ; le vérificateur de sécurité d'URL est un produit séparé sur check.qr.abundera.ai. Vérifier si un QR code est sûr

Modèle de menace

Parce que le générateur ne collecte, ne stocke ni ne transmet aucune donnée utilisateur (les deux points de terminaison ci-dessus ne traitent que ce que vous leur envoyez explicitement), les menaces les plus courantes des applications web — vol de credentials, violation de base de données, détournement de session, injection côté serveur — ne s'y appliquent pas. La surface d'attaque restante est le bundle d'assets statiques (HTML, CSS, JavaScript) servi depuis notre origine. Nous concevons en supposant :

Politique de Sécurité du Contenu — par directive

La politique ci-dessous est lue depuis le fichier _headers déployé au moment de la compilation de cette page, elle ne peut donc pas diverger de ce que l'edge envoie. Vérifiez-la dans les en-têtes de réponse de toute requête.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://abundera.ai 'wasm-unsafe-eval' https://challenges.cloudflare.com;
  worker-src 'self' blob:;
  style-src 'self' 'unsafe-inline' https://abundera.ai;
  font-src 'self';
  img-src 'self' data: blob: https:;
  connect-src 'self' https: https://challenges.cloudflare.com;
  frame-src 'self' https://challenges.cloudflare.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self'

Ce que chaque directive nous permet de faire et où elle représente un compromis :

Ce que CSP ne peut pas faire

CSP limite les origines depuis lesquelles le navigateur chargera du code. Elle ne vérifie pas ce que fait le code chargé. Si notre origine était compromise, le premier point du modèle de menace, le script de l'attaquant s'exécuterait avec les mêmes permissions que les nôtres, y compris les autorisations connect-src et img-src ci-dessus. Nos défenses contre ce scénario se situent en amont de CSP : les déploiements passent par un seul compte Cloudflare avec des jetons à portée limitée, les noms de fichiers d'assets sont hachés par contenu, ce qui fait qu'un fichier substitué change chaque URL qui le référence, et le service worker ne met en cache que les réponses GET de même origine. Le manifeste décrit le site tel qu'il est livré. Ce n'est pas une affirmation qu'aucune page web ne pourrait jamais envoyer de données quelque part, et nous préférons que vous nous teniez à cette déclaration plus étroite et vérifiable.

Des politiques CSP différentes s'appliquent à /bio/* (img-src assoupli pour les avatars fournis par l'utilisateur) et /embed/* (frame-ancestors assoupli pour l'intégration intentionnelle). Les deux sont documentées dans site/_headers.

En-têtes de transport et de cadrage

Service worker

Notre service worker (site/sw.js) met en cache uniquement les assets de même origine. Le gestionnaire fetch rejette explicitement les requêtes cross-origin et les méthodes non-GET — vous pouvez lire la logique dans /sw.js (le code source est livré assez peu minifié pour rester lisible). Les écritures en cache sont enveloppées dans event.waitUntil() afin qu'elles ne puissent pas être abandonnées en cours de navigation.

Assainissement des entrées

Chaque chemin de rendu qui accepte une entrée utilisateur la traite comme du texte non fiable :

Récupération d'images cross-origin

Quand un utilisateur colle une URL https: comme photo vCard ou logo, le navigateur la récupère en respectant CORS et la liste d'autorisation img-src de notre CSP. L'image est rendue dans un canvas. Elle ne devient jamais du DOM actif, ne s'exécute jamais comme du code, et n'atteint jamais notre origine — la récupération se fait navigateur → image distante, et le résultat est rendu côté client. Un attaquant contrôlant une URL d'image distante peut savoir que l'URL a été chargée (une ligne de log sur son propre serveur) mais ne peut pas exfiltrer quoi que ce soit de notre page.

Intégrité des Sous-Ressources (SRI)

Tout le JavaScript et CSS que nous livrons est de même origine. Nous ne chargeons pas de scripts ou feuilles de style tiers, donc les hash SRI ne sont pas applicables. Si jamais nous chargeons un asset tiers, nous lui ajouterons un attribut integrity SRI et documenterons le processus de mise à jour des hash dans cette page.

Signaler une vulnérabilité

Si vous découvrez un problème de sécurité affectant Abundera QR — que ce soit dans notre code, notre déploiement, ou une dépendance que nous livrons — veuillez le signaler de façon privée à security@abundera.ai. Nous visons un triage sous 72 heures. Vous pouvez également nous contacter via les coordonnées de notre fichier /.well-known/security.txt.

Pas de programme de bug bounty (pour l'instant)

Nous n'offrons actuellement pas de primes payées, mais chaque rapport valide confirmé reçoit un crédit dans le changelog et nos remerciements publics.

Vérifiez tout ce qui précède

Chaque affirmation sur cette page est falsifiable depuis les DevTools de votre navigateur sans nous faire confiance :

Contact

Divulgations de sécurité : security@abundera.ai

Dernière mise à jour : 2026-09-03. Prochaine révision : 2026-12-03.