Sécurité

Authentification

• Les mots de passe sont hachés avec scrypt et un sel propre à chaque utilisateur.
• La connexion compare à une empreinte factice lorsque l’adresse est inconnue, de sorte qu’un échec prend le même temps que le compte existe ou non.
• Les sessions sont des jetons aléatoires opaques dans un cookie httpOnly, SameSite=Lax (Secure en production). Seule une empreinte SHA-256 est conservée côté serveur.
• Changer ou réinitialiser un mot de passe révoque toutes les sessions sur tous les appareils.
• Les jetons de vérification et de réinitialisation sont à usage unique, hachés au repos, et expirent (24 heures et 1 heure respectivement).
• La connexion Google vérifie un paramètre d’état CSRF et refuse de lier une adresse Google non vérifiée à un compte existant.

Autorisation

• Contrôle d’accès par rôles avec une table de permissions, et non des comparaisons de rôle éparpillées. Rôles : USER, AGENT_BUILDER, SUPPORT, MANAGER, ADMIN, SUPER_ADMIN.
• Toute requête qui lit des données client est restreinte à l’identifiant de l’utilisateur, si bien qu’un identifiant venant d’un autre compte aboutit à un 404 plutôt qu’à une fuite.
• Les routes d’administration vérifient la permission précise dont elles ont besoin, indépendamment du layout qui affiche la page.
• Personne ne peut modifier son propre rôle ou statut, ni accorder un rôle supérieur au sien.

Protection des requêtes

• CSRF : les mutations authentifiées par cookie exigent une correspondance d’Origin et un jeton à double soumission.
• Limitation de débit sur la connexion, l’inscription, la réinitialisation de mot de passe, les exécutions d’agents, les formulaires publics et les webhooks.
• Validation des entrées avec Zod à chaque frontière d’API. Une entrée invalide renvoie des erreurs par champ, jamais une trace d’exécution.
• L’accès à la base de données passe par Prisma avec des requêtes paramétrées ; il n’y a pas de SQL construit par concaténation.
• Les requêtes sortantes des agents et des nœuds de workflow rejettent la boucle locale et les plages de réseaux privés, ce qui bloque la SSRF.

Secrets

• Les identifiants d’intégration et les jetons OAuth sont chiffrés en AES-256-GCM avant stockage et ne sont jamais envoyés à un navigateur.
• Les clés d’API sont stockées sous forme d’empreintes SHA-256. La clé brute apparaît exactement une fois, dans la réponse de création.
• Les clés d’API des fournisseurs ne vivent que dans les variables d’environnement du serveur. Tous les appels de modèle se font côté serveur.
• Les journaux passent par un filtre de masquage qui supprime les champs ayant la forme d’un identifiant.

Exécution des agents

• Les outils déclarent un niveau de risque : READ, WRITE ou DESTRUCTIVE. Une version d’agent déclare le niveau le plus élevé qu’elle peut exécuter automatiquement.
• Un appel au-dessus de ce plafond est refusé, enregistré comme en attente d’approbation, et signalé au modèle comme non effectué.
• Les exécutions sont bornées par un nombre d’étapes, un budget de jetons et un délai maximal.
• Chaque étape est conservée avec son entrée, sa sortie, sa durée et son niveau de risque.

Paiements

• PROMIVO ne voit ni ne stocke jamais de données de carte. Notre prestataire de paiement s’en charge de bout en bout.
• Les signatures des webhooks sont vérifiées avant que la charge utile ne soit lue comme des données.
• Chaque événement est enregistré sous une contrainte d’unicité, de sorte qu’une nouvelle livraison est reconnue et ignorée plutôt qu’appliquée deux fois.
• Les droits d’accès ne sont accordés que par le gestionnaire de webhooks, jamais par une redirection de succès côté client.

Signaler une vulnérabilité

Nous contacter avec les étapes pour la reproduire. Merci de nous laisser un délai raisonnable pour corriger le problème avant toute divulgation publique.