Sécurité

Où il tourne

L’application tourne dans des conteneurs reconstruits depuis les sources à chaque déploiement ; la base et les files ne sont pas joignables depuis Internet.

En transit

• –Chaque page et chaque appel d’API sont servis en HTTPS, avec HTTP Strict Transport Security.
• –Chaque réponse porte des en-têtes qui interdisent la détection de contenu et l’affichage dans le cadre d’un autre site, limitent le référent, et coupent caméra, micro, géolocalisation et paiement.
• –La version web d’une campagne est servie dans un bac à sable où aucun script ne tourne, et les aperçus d’un e-mail sont isolés de même.
• –Le relais SMTP se joint en TLS sur le port 465. Vers le serveur SMTP d’un fournisseur d’envoi, Lekalao utilise TLS dès le départ sur le port 465 et STARTTLS sur les ports 25 et 587, et n’envoie jamais en clair sur ces ports.

Au repos

• –Les identifiants des fournisseurs d’envoi, les secrets qui signent les webhooks et les clés DKIM privées sont chiffrés en base (AES-256, avec la clé de l’application), et ne sont plus jamais affichés une fois enregistrés.
• –Les mots de passe ne sont gardés que sous forme d’empreintes bcrypt. Les jetons d’API s’affichent une fois, à leur création, et ne sont gardés que sous forme d’empreintes.
• –Un modèle transactionnel peut demander que le contenu de ses e-mails ne soit pas gardé.

Comptes et accès

• –Rien dans le service n’est accessible avant que l’adresse e-mail du compte soit vérifiée.
• –La double authentification par application, et les passkeys. Une équipe peut exiger l’une ou l’autre de chaque membre.
• –Les tentatives de connexion sont limitées, et l’API aussi : 120 appels par minute et par jeton par défaut.
• –Quatre rôles : Propriétaire, Éditeur, Rédacteur, Lecteur. Écrire, envoyer et exporter sont des droits distincts ; un Rédacteur prépare mais n’envoie ni n’exporte.
• –Quatre yeux, si l’équipe le demande : une campagne ne part qu’une fois qu’un autre membre que celui qui l’a demandée a approuvé exactement ce qui partira.
• –Les jetons d’API portent leurs propres droits (lecture, écriture) et se révoquent depuis les réglages.

Qui a fait quoi

Chaque action qui a changé quelque chose, chaque téléchargement qui fait sortir des données et chaque connexion écrit une ligne au journal d’activité de l’équipe : qui, quoi, sur quoi, depuis quelle adresse IP, par le navigateur ou par quel jeton d’API. Rien de ce que quiconque a saisi n’y est gardé. Les propriétaires peuvent le consulter et l’exporter ; il est gardé 400 jours.

Protéger les destinataires et les réputations

• –Sur le service partagé, une équipe n’envoie que depuis des domaines qu’elle a ajoutés et vérifiés.
• –Une campagne se met en pause d’elle-même quand ses plaintes ou ses rebonds franchissent les seuils ; les adresses qui ont rebondi pour de bon ou se sont plaintes sont bloquées pour toute l’équipe.
• –Aucun e-mail marketing ne part sans lien de désabonnement ni adresse postale.
• –Les webhooks sortants sont signés en HMAC-SHA256. Les notifications de paiement de la passerelle sont vérifiées par leur signature et une fenêtre de temps.
• –Les adresses que Lekalao va chercher pour un client — flux, webhooks, vérification de liens — sont refusées quand elles pointent vers le serveur lui-même, un réseau privé ou une adresse de métadonnées cloud.
• –Ce qu’une équipe écrit sur ses pages publiques est échappé, et les images SVG sont refusées.

Moins de données, gardées moins longtemps

L’adresse IP d’une ouverture ou d’un clic n’est pas enregistrée, et aucune base géographique n’est embarquée. Les adresses e-mail sont retirées des rapports d’erreurs avant qu’ils partent. Ouvertures, clics et journaux de remise sont effacés après 365 jours, chaque nuit. Chaque équipe décide combien de temps sont gardés les preuves de consentement et les désabonnés, et peut exporter ou effacer les données d’une personne depuis sa fiche.

Sauvegardes et reprise

La base et les fichiers stockés sont sauvegardés chaque nuit et gardés hors du serveur de production, chiffrés, avec au moins sept copies quotidiennes et quatre hebdomadaires. La clé qui déchiffre les identifiants stockés est gardée avec le même soin que la base. Une restauration est répétée chaque mois sur une autre machine : une session est ouverte, les identifiants d’un fournisseur sont relus, les données d’un abonné sont téléchargées.

Comment c’est fait

Plus de 1 000 tests automatisés et une analyse statique du code tournent sur chaque modification, en intégration continue.

Les données de chaque équipe sont séparées de celles des autres : chaque requête est filtrée par équipe, l’équipe est choisie avant que quoi que ce soit de nommé dans une adresse soit cherché, et une requête connectée sans équipe est refusée plutôt que servie. Les tests commencent chaque requête sans équipe, comme en production, et tentent d’atteindre les listes, campagnes, abonnés, fournisseurs d’envoi et pages d’une autre équipe par l’interface et par l’API.

Ce que nous ne prétendons pas

Lekalao ne détient aucune certification de sécurité (comme ISO 27001 ou SOC 2) et n’a pas encore fait l’objet d’un test d’intrusion externe. Il ne s’engage sur aucun niveau de disponibilité, et n’offre pas d’authentification unique. Quand l’un de ces points change, cette page le dit, avec la date.

Signaler une vulnérabilité

Si vous trouvez une faiblesse, écrivez à hello@lekalao.com avec « Sécurité » dans l’objet, et laissez-nous le temps de la corriger avant d’en parler. N’accédez pas à des données qui ne sont pas les vôtres, ne les modifiez ni ne les supprimez, et ne dégradez pas le service. Nous répondons à chaque signalement, vous disons ce que nous avons fait, et vous remercions nommément si vous le souhaitez.