Sécurité

1. Ce qu'est cette page

Cette page décrit les mesures techniques que Cardim applique aujourd'hui, rédigées à partir du code tel qu'il est publié. Ce n'est pas un contrat : les engagements contractuels figurent dans les Conditions Générales de Service, et ce que nous faisons des données personnelles, et sur quelle base, figure dans la Politique de confidentialité.

Cardim est un produit récent, exploité par une très petite équipe. Nous préférons le dire ici, d'emblée, plutôt que de le laisser deviner : la section 7 énumère ce qui n'existe pas.

2. Où sont les données

Les réservations et les données des clients sont dans une base de données Postgres hébergée par Neon à Londres, au Royaume-Uni, sur une infrastructure AWS dans la région eu-west-2. L'application tourne chez Vercel, les e-mails transactionnels sont acheminés par Resend et les rapports d'erreur partent chez Sentry. La liste complète des prestataires, avec la finalité de chacun, figure à la section 5 de la Politique de confidentialité.

Tout le trafic est servi en HTTPS. Le chiffrement du stockage lui-même est celui que ces prestataires publient et ne relève pas de nous ; au niveau de l'application, ce que nous chiffrons ou hachons est exactement ce qu'énumère la section suivante, et rien d'autre.

3. Mots de passe, clés et liens

Rien de cette liste n'est conservé sous une forme qu'une lecture de la base de données rendrait réutilisable, avec une exception signalée : les jetons de calendrier doivent être renvoyés au fournisseur, ils sont donc chiffrés plutôt que hachés.

• Mots de passe des commerçants — jamais conservés. Nous gardons le résultat de scrypt, avec un sel différent par utilisateur, et la vérification se fait par comparaison à temps constant.
• Liens de réinitialisation de mot de passe — 32 octets d'aléa cryptographique, et la base ne garde que le SHA-256 du jeton : lire la base de données ne permet de réinitialiser le mot de passe de personne.
• Jetons Google Agenda et Outlook — chiffrés en AES-256-GCM avant écriture, avec un trousseau qui permet de remplacer la clé sans rendre illisible ce qui est déjà stocké.
• Sessions et liens de réservation — identifiants de 128 bits issus du générateur cryptographique du système. La session voyage dans un cookie httpOnly et expire au bout de 30 jours.

Le lien que le client reçoit par e-mail est à lui seul l'autorisation de consulter, modifier ou annuler cette réservation : côté client, il n'y a ni compte ni mot de passe. C'est pourquoi ces liens, et les adresses e-mail, sont retirés des rapports d'erreur avant de quitter l'application, et pourquoi les formulaires publics limitent le nombre de tentatives par origine.

4. Ce que la base de données interdit

Deux réservations ne peuvent pas occuper la même ressource au même moment, et la garantie ne réside pas dans le code applicatif : chaque ligne d'occupation porte son propre intervalle de temps, et une contrainte d'exclusion Postgres refuse tout chevauchement. Deux requêtes arrivant au même instant ne peuvent pas gagner toutes les deux, quoi qu'il se passe au-dessus de la base.

Un déclencheur distinct empêche qu'un même client se retrouve avec deux réservations qui se chevauchent. Pour les tables et les salles à capacité partagée, le nombre de couverts est vérifié dans la même transaction, avec des verrous par ressource toujours pris dans le même ordre, afin que deux requêtes simultanées ne s'attendent pas mutuellement.

5. Qui voit quoi

Chaque écran du tableau de bord n'interroge que les données du commerçant de la session, et les demandes d'export et d'effacement exigent ce même périmètre : un commerçant ne peut ni exporter ni effacer les enregistrements d'un autre.

Il existe une console interne, utilisée pour exploiter le service, dont l'accès est limité à une liste fermée d'adresses e-mail définie dans la configuration du serveur. Lorsque cette liste n'est pas configurée, la console refuse tout le monde au lieu de laisser entrer.

6. Conservation, effacement et export

Un nettoyage s'exécute périodiquement et supprime ce qui ne sert plus à rien :

• les sessions dont la validité a expiré — une session abandonnée reste un identifiant vivant tant que la ligne existe ;
• les réservations temporaires de place déjà caduques ;
• les enregistrements de limitation de tentatives de plus de 24 heures, qui contiennent du reste une empreinte et non l'adresse d'origine ;
• les inscriptions en liste d'attente pour des dates vieilles de plus de 30 jours, qui sont un nom, un téléphone et un e-mail appartenant à quelqu'un qui n'est jamais devenu client.

Les réservations et les clients ne sont pas supprimés par minuterie : ils constituent le registre d'activité du commerçant. L'effacement se fait sur demande et prend la forme d'une anonymisation sur place — la réservation, l'heure et le montant subsistent, l'identité de la personne disparaît, y compris les remarques en texte libre et les événements recopiés dans le calendrier connecté. Si l'un de ces événements ne peut pas être supprimé, le commerçant en est informé plutôt que rassuré.

Un commerçant peut demander l'export de ses données et la suppression complète de son compte.

7. Ce que nous n'avons pas

Cette liste existe parce que l'autre solution serait de laisser la question sans réponse en espérant que personne ne la pose :

• nous n'avons ni certification SOC 2, ni ISO 27001, ni aucune autre ;
• il n'y a eu ni audit de sécurité externe, ni test d'intrusion par un tiers ;
• nous ne proposons pas d'accord de niveau de service sur la disponibilité, et la disponibilité réelle dépend des prestataires cités à la section 2 ;
• nous n'avons pas de programme de récompense pour la remontée de vulnérabilités.

8. Signaler un problème

Si vous avez trouvé une faille de sécurité, écrivez à support@usecardim.com en indiquant les étapes pour la reproduire. Nous répondrons et corrigerons ce qui est à notre portée, et nous vous demandons de ne pas la divulguer publiquement avant qu'elle ne soit corrigée.