Sécurité

Connexion

Une seule porte d'entrée : un code à six chiffres envoyé par e-mail. Pas de mot de passe susceptible de fuiter, pas de lien magique : le lien a été supprimé plutôt que conservé comme second accès, parce que deux portes font deux surfaces d'attaque, et que l'une des deux est toujours la plus faible.

Un code reste valable 10 minutes.

Les codes sont stockés sous forme de HMAC calculé avec un secret serveur, pas sous forme de simple hash. Toute la différence est là : un code à six chiffres offre environ vingt bits d'espace de préimage. Son empreinte sans clé se précalcule donc en moins d'une seconde sur un ordinateur portable, et une simple fuite en lecture de la base de données aurait livré tous les codes de connexion en cours de validité. Un HMAC exige aussi le secret, et un secret ne se trouve pas dans une sauvegarde de base de données.

La valeur stockée est aussi liée à l'adresse pour laquelle le code a été émis : une ligne extraite de la table ne peut donc pas valider la connexion d'un autre compte.

Sessions

Une durée glissante, pas fixe : le cookie est réémis à chaque navigation, si bien qu'un utilisateur actif chaque jour n'est pas déconnecté sans prévenir au 30e jour.

Sans mémorisation, la fenêtre dure volontairement une journée, au lieu d'un cookie qui expire à la fermeture du navigateur : la plainte à l'origine de cette règle portait sur des déconnexions intempestives, et un onglet qui plante ne devrait pas vous coûter votre session.

Limitation de débit et verrouillage

L'envoi d'un code est limité en débit par adresse IP. C'est la vérification qui porte le verrouillage, et cette séparation est voulue : quand l'envoi appliquait lui aussi le verrouillage, un attaquant pouvait soumettre cinq codes erronés et fermer complètement à la victime l'accès à son propre compte. Le verrou a sa place là où l'on tente de deviner.

Le cloisonnement entre organisations

Chaque requête est limitée à une organisation. Les rôles et les permissions par membre sont décrits dans Organisations et rôles. L'application de ces règles ne relève pas de l'interface : une route qui lit des données d'organisation vérifie d'abord l'appartenance de l'appelant.

Identifiants au repos

Les tokens d'accès Shopify et les tokens des connecteurs sont chiffrés en AES-256-GCM. Les clés API émises par BoostEcom sont stockées sous forme de hash SHA-256 : nous ne pouvons pas vous réafficher une clé après sa création, puisque nous ne l'avons pas.

Aucune API ne renvoie de token, et aucun token n'est inscrit dans les logs.

Journal d'audit

Les événements de sécurité et de facturation sont inscrits dans un journal d'audit, et les actions d'administration globales dans un journal distinct. Vous pouvez consulter votre propre activité sur /account/settings/activity.

Signaler un problème

Si vous découvrez une vulnérabilité, signalez-la-nous via /contact plutôt que dans un fil public. La politique d'usage acceptable et la page sécurité en fixent le cadre formel.