Sécurité

Ce que Hela fait pour que les intégrations n'ouvrent pas la porte.

Les secrets

• Les identifiants des connexions (clés, jetons, certificats) sont chiffrés AES-256-GCM avant d'être écrits, avec INTEGRATIONS_KEY, versionnée : une rotation de clé ne demande aucun rechiffrement manuel, l'ancienne reste lisible le temps de la bascule.
• Ils ne sont jamais renvoyés par l'API ni affichés par l'écran ; un champ renseigné montre Renseigné.
• Les clés d'API ne sont stockées que par leur empreinte SHA-256 ; les secrets de webhooks, chiffrés comme les identifiants.
• Les journaux de connexion sont expurgés : un jeton reconnaissable (Bearer …, sk_live_…, whsec_…, hela_live_…, une longue chaîne opaque) qui apparaîtrait dans une réponse de partenaire est remplacé par ••• avant d'être écrit.

Les clés d'API

• Portées : un sous-ensemble explicite des permissions ; les permissions qui touchent aux personnes et à l'argent du compte sont interdites aux clés.
• Mode test : lecture seule, par construction.
• Limite de débit par clé, et 429 au-delà.
• Révocation immédiate.
• Chaque requête de clé est journalisée dans l'audit de l'entreprise avec le préfixe de la clé (request_events).

Les webhooks sortants

• HTTPS obligatoire ; adresses privées, locales et de lien local refusées à la création et à chaque envoi (résolution DNS vérifiée : un nom qui pointe vers 10.0.0.1 est refusé) ; redirections non suivies ; délai de 15 secondes.
• Signature HMAC-SHA256 horodatée sur chaque envoi ; fenêtre de validité de cinq minutes.
• Pas de corps au-delà de ce que l'événement porte : jamais de secret, jamais de données d'un autre client.

Les webhooks entrants

• Une adresse par connexion, non devinable (/integrations/inbound/<fournisseur>/<identifiant de connexion>).
• La signature du partenaire est vérifiée quand il en fournit une (Stripe, Mollie, Wave, Flutterwave, Yousign, DocuSign, M-Pesa, MTN…) ; sinon, l'événement est relu chez le partenaire avant d'être cru. Une notification qui ne correspond à rien est journalisée et ignorée.
• Le corps brut est conservé pour la vérification, jamais interprété avant.

OAuth

• Flux authorization code avec PKCE et un état signé, à usage unique, lié à l'entreprise et à l'utilisateur qui a cliqué ; dix minutes de validité.
• Portées minimales : drive.file (un dossier), Files.ReadWrite.AppFolder, et jamais l'accès complet à un Drive ou une boîte mail.
• Les jetons de rafraîchissement sont chiffrés comme le reste ; la reconnexion est demandée quand le partenaire les révoque.

L'isolement des entreprises

Chaque entreprise a son schéma de base de données ; les connexions, clés, webhooks et travaux portent l'identifiant de l'entreprise et sont filtrés par lui dans chaque requête. Une clé d'API d'une entreprise ne peut pas nommer une autre entreprise dans un chemin : 404.

Les régimes fiscaux

• Les certificats et clés privées (VFD, EFRIS) sont chiffrés comme les autres identifiants ; les signatures sont calculées côté serveur et la clé ne quitte jamais la base.
• Le journal scellé rend toute modification après coup visible, ce qui protège l'entreprise autant que l'administration.

Signaler

Une faille se signale à security@hela.co. Nous accusons réception sous 48 heures et publions un correctif avant de publier le détail.