Anti-quishing côté émetteur. Résidence des données côté stockage.
Chaque lien Pro passe par un pipeline anti-quishing en sept couches à l'émission, à chaque changement de destination, et selon un calendrier tournant. Le journal de scan contient uniquement le pays et la classe d'appareil : pas d'IP, pas d'user agent, pas de cookie, pas de profil comportemental à fuir. Le D1 mono-région est disponible sur Agency et Custom Enterprise.
Données que nous collectons
Chaque octet qui arrive sur nos serveurs appartient à l'un de ces quatre buckets :
Données de compte
Email, niveau de plan, statut du plan, IDs client + abonnement Stripe, nom d'équipe + label d'espace de travail optionnels. C'est tout. Pas de téléphone, pas d'adresse (l'adresse de facturation reste chez Stripe), pas de profil comportemental.
Données de code
L'URL de destination, un shortcode Base58 de 7 caractères, un label + des tags que vous définissez, le design QR optionnel (couleurs / logo / cadre), un verrouillage par mot de passe optionnel, une planification optionnelle. Vous en êtes propriétaire ; exportable en CSV à tout moment.
Données de scan
Bucket jour UTC + pays (depuis CF-IPCountry) + classe d'appareil (mobile / tablet / desktop / unknown). Le User-Agent brut est supprimé immédiatement après la classification. L'IP n'entre jamais en base de données. Mis en cache dans KV pour le chemin de redirection, agrégé dans D1 via ctx.waitUntil. Les agrégats de pays sous 5 scans sont regroupés dans « Other » pour éviter la ré-identification.
Métadonnées d'audit / facturation
Journal append-only des mutations (qui a fait quoi, quand, dans quel périmètre), rétention 180 jours. Événements webhook Stripe dédupliqués pour l'idempotence, aucune PII client au-delà de l'ID client Stripe. Journal des requêtes GDPR (export / suppression / restauration), conservé après suppression du compte pour preuve de traitement dans les délais.
Pour le schéma complet, voir docs/SCHEMA.md dans notre dépôt source ; chaque colonne est documentée avec une politique de rétention.
Où les données sont hébergées
| Surface | Fournisseur | Région | Option mono-région ? |
|---|---|---|---|
| Tableau de bord + API | Cloudflare Pages Functions | Edge global (PoP le plus proche) | Oui, Agency+ uniquement |
| Enregistrements de codes (D1) | Cloudflare D1 (SQLite) | Région primaire assignée au provisionnement (aujourd'hui : ENAM) | Oui, shard par tenant Agency+ |
| Chemin de redirection (KV) | Cloudflare Workers KV | Répliqué sur l'edge globalement pour un p99 <50ms | Non disponible (la réplication est le produit) |
| Sauvegardes chiffrées | Cloudflare R2 | Région primaire assignée à la création du bucket | Oui, bucket juridictionnel EU / APAC sur demande |
| Paiements | Stripe | US, gestion des PII régionalisée via la propre résidence de Stripe | Via contrat Stripe |
| Email transactionnel | ZeptoMail (Zoho) | IN (région EU de Zoho disponible sur demande) | Oui, région EU Zoho |
Ce qui franchit une frontière, exactement
- Les scans ne franchissent jamais une frontière avec perte de données. Un scan depuis Lisbonne touche le PoP Cloudflare de Lisbonne, le worker écrit jour/pays/appareil dans KV à l'edge, et agrège de façon asynchrone dans D1 dans sa région primaire. L'IP du scanner d'origine vit dans l'état éphémère de la requête HTTP Cloudflare pour la durée de cette requête et n'est jamais persistée dans notre base de données.
- Les requêtes du tableau de bord se terminent au PoP Cloudflare le plus proche et appellent D1 via le réseau privé de Cloudflare. Nos Pages Functions lisent/écrivent D1 dans sa région assignée ; le PoP edge sert le bundle HTML + JS depuis le cache d'actifs statiques global.
- Les webhooks Stripe franchissent la frontière une fois, Stripe (US) envoie un POST à notre endpoint Cloudflare Pages, qui vérifie le HMAC, écrit une ligne minimale (event_id, type) pour l'idempotence, et dispatche les événements en aval.
- L'email transactionnel (Zepto) franchit la frontière une fois par envoi, notre worker remet un modèle rendu à l'API de Zepto ; Zepto le livre au serveur de messagerie du destinataire. Le contenu est constitué de liens d'invitation, de notifications du cycle de vie de facturation et d'alertes de plafond de scans, aucune donnée de scan client.
Pipeline anti-quishing
Le phishing par QR a augmenté de 146 % au T1 2026. Les fournisseurs de liens courts standard réagissent après une plainte client. Nous vérifions chaque lien à l'émission, à chaque changement de destination de notre côté, et selon un calendrier tournant parce qu'un client peut réorienter sa propre URL sur son propre serveur sans jamais appeler notre API. Le même pipeline de renseignement sur les menaces qui alimente notre scanner public sur check.qr.abundera.ai s'exécute sur chaque lien que nous émettons.
Sept couches de détection, chacune avec une demande de brevet US en cours. Chaque couche alimente un verdict unifié ; une correspondance sur n'importe laquelle peut bloquer une création, refuser un changement de destination, ou suspendre un lien déjà actif.
| Couche | Ce qu'elle détecte | Quand elle s'exécute |
|---|---|---|
| Mutabilité de la chaîne de redirections | Combien de parties indépendantes contrôlent le chemin entre notre lien court et la page finale. Une chaîne à deux sauts via le redirecteur d'un tiers représente une classe de risque différente d'une destination directe. | Création, changement de destination, re-vérification tournante |
| Analyse de payload multi-modal | WiFi, contact, téléphonie, mail, calendrier, géolocalisation, cryptomonnaie, intent Android et payloads inline reçoivent chacun un analyseur spécifique au type. Les schémas bloqués refusent à la soumission. | Création, changement de destination |
| Cloaking crawler vs. navigateur | Pages qui servent du contenu propre aux scanners et du phishing aux humains. Détecté par des fetches parallèles avec variance de fingerprint contrôlée et un score de divergence. | Création, re-vérification tournante |
| Mutabilité du serveur de destination | Domaines fraîchement enregistrés, certificats tout neufs, TLDs à fort taux de rotation, HSTS manquant et dégradation de schéma de transport. Indépendant de la chaîne de redirections ; une chaîne statique à un saut vers un certificat de six jours sur un TLD douteux est quand même signalée. | Création, changement de destination, re-vérification tournante |
| Provenance d'instance physique | Registre de hash participatif indexé par payload décodé. Un seul QR scanné dans de nombreuses régions disparates en peu de temps est identifié comme candidat à une attaque par sticker. Chaque lien que nous émettons reçoit une entrée de provenance propre à la création, ce qui permet de détecter les attaques par superposition contre des codes Pro légitimes. | Continu |
| Divergence de marque visuelle | Si un code porte un logo de marque dont l'ensemble de domaines canoniques n'inclut pas la destination décodée, le code est divergent par rapport à la marque. S'applique à tous les codes Pro qui utilisent notre fonctionnalité de logo centré ; un hameçonneur ne peut pas diffuser un code avec le logo Chase pointant vers un domaine non-Chase. | Création, changement de logo, changement de destination |
| Topologie capteur / lieu | Pour les codes liés à un lieu (parcomètres, enregistrement hôtelier, menus de restaurant, expositions de musée), le contexte RF ambiant de l'appareil qui scanne est vérifié par rapport à la topologie enregistrée pour ce lieu. Un écart génère une anomalie de contexte capteur dès le premier scan d'un sticker frauduleux. Niveau Enterprise ; l'opérateur du lieu enregistre la topologie attendue à la création du code. | Chaque scan |
Le problème du changement côté client
L'URL de destination d'un lien Pro vit sur le serveur du client, pas le nôtre. Le client peut réorienter example.com/promo d'une vraie promo vers une page de phishing sans jamais appeler l'API Abundera. Nous traitons cela comme le vecteur d'abus principal, pas un cas limite. Des re-vérifications tournantes des destinations actives s'exécutent selon un calendrier, et notre couche de détection de cloaking cible spécifiquement les pages qui changent après la soumission. Quand une destination commence à échouer aux vérifications après la création, le lien est mis en pause automatiquement, le propriétaire reçoit un email avec le verdict précis, et nous journalisons l'événement dans la piste d'audit.
Faux positifs et recours
Le renseignement sur les menaces se trompe parfois. Une marque légitime sur un certificat fraîchement émis, une vraie promo dont la page a légitimement changé, un domaine déplacé. Chaque blocage et chaque mise en pause automatique inclut la couche de verdict précise qui a déclenché l'alerte, l'entrée qui l'a provoquée, et un recours en un clic qui remonte à un humain en moins d'un jour ouvrable. Nous préférons mettre en pause plutôt que supprimer ; un lien en pause peut être réactivé en quelques secondes une fois le recours traité.
Résidence mono-région (Agency+ et Custom Enterprise)
Pour les acheteurs EU-only ou APAC-only, les clients Agency peuvent demander :
- D1 placé dans une juridiction unique (EU : EEUR ou WEUR ; APAC : APAC). Cloudflare respecte un indice
locationà la création de la base de données ; nous créons un shard D1 par tenant dans la région demandée (ADR-0010). - Bucket R2 dans la même juridiction, les sauvegardes chiffrées nightly D1 → R2 atterrissent dans la région correspondante.
- Région EU Zepto pour l'email transactionnel, configurée au niveau du service, aucun changement de code.
- KV reste global, la réplication sur l'edge est au cœur de la garantie de redirection <50ms. Si le KV mono-région est une exigence ferme, parlez-nous ; nous évaluerons si une variante Worker régionale uniquement est faisable pour votre campagne.
Le prix du module complémentaire mono-région est forfaitaire (sans majoration par siège) et dépend de la combinaison spécifique. Écrivez à enterprise@abundera.ai avec votre juridiction cible + volume de scans prévu et nous établirons un devis.
Posture de conformité
- GDPR, données minimales par conception (pays + classe d'appareil uniquement, sans IP, sans UA, sans cookies) plus export en un clic et suppression définitive sous 30 jours. DPA + EU SCCs disponibles pour tous les niveaux payants.
- CCPA, couvert par la même surface d'export + suppression. La vente de données n'est pas quelque chose que nous faisons : pas de partage tiers, pas de partenaires publicitaires, pas de reciblage.
- Provisionnement SSO + SCIM, SSO SAML 2.0 + OIDC et cycle de vie utilisateurs & groupes SCIM 2.0 (niveaux Agency + Custom Enterprise). Conformité RFC 7643/7644 vérifiée (20/20 sur la suite de tests dérivée de PingIdentity). Le flag de fonctionnalité par connexion signifie que SCIM est désactivé par défaut et activé par client ; limité à 50 RPS par token ; journalisé dans l'audit. Okta/Entra/JumpCloud fonctionnent aujourd'hui en tant qu'applications SCIM personnalisées pendant que les inscriptions aux catalogues de partenaires sont en cours.
- SOC 2 Type II, en cours de cadrage. Processus de 6 à 9 mois. Si c'est une exigence ferme pour vous, écrivez à enterprise@abundera.ai ; nous pouvons partager l'état actuel + le calendrier prévu.
- PCI-DSS, hors périmètre pour nous directement ; les paiements sont gérés de bout en bout par Stripe (certifié PCI Level 1).
Divulgation de failles de sécurité
Vous avez trouvé une vulnérabilité ? Écrivez à security@abundera.ai. Divulgation coordonnée, nous accusons réception sous 24h (jours ouvrables), trions sous 72h, et coordonnons avec vous un calendrier de correction + divulgation. Pas encore de programme de bug bounty ; nous reconnaissons publiquement les chercheurs sur abundera.ai/security/thanks/ une fois le correctif déployé.