Signaler une vulnérabilité

Écrivez à security@signetauth.com. Un rapport en texte brut convient et ne justifie pas de retarder l'envoi. Indiquez votre découverte et son impact, la façon de la reproduire, ainsi que la version de Signet et le type de déploiement si vous les connaissez. N'ouvrez pas de signalement public et ne passez pas par une demande de soutien ordinaire; une demande de soutien est lue par plus de personnes, plus tôt qu'un rapport de sécurité ne devrait l'être.

Ces délais sont délibérément ceux qu'une petite équipe peut tenir pendant une mauvaise semaine; manquer un délai publié serait pire que n'en publier aucun. Un rapport classé sécurité est traité par une personne : jamais de réponse automatique, jamais de triage par un agent, jamais de fermeture automatique.

Cadre de protection juridique. Les recherches de bonne foi menées selon ce processus ne feront pas l'objet de poursuites. La bonne foi signifie s'arrêter à la preuve, ne pas accéder à des données qui ne vous appartiennent pas ni les conserver, ne pas dégrader le service pour autrui et nous laisser une possibilité raisonnable de corriger le problème d'abord. Aucun accord de confidentialité n'est requis pour signaler un problème. Il n'y a pas de prime aux bogues; nous offrons une mention dans les notes de version et un remerciement nominatif si vous le souhaitez.

Dans le périmètre : le moteur et chaque point de terminaison qu'il sert, le parcours de vérification de licence et nos instances hébergées. Hors périmètre : résultats de scanners sans impact démontré, déni de service volumétrique, ingénierie sociale. Les bogues d'épuisement des ressources, où une requête peu coûteuse nous coûte démesurément, sont dans le périmètre et nous intéressent. L'annonce lisible par machine se trouve à /.well-known/security.txt.

Où résident vos données

Chaque utilisateur, session et secret est une ligne dans PostgreSQL : votre propre base de données, dès la première connexion. Le transport utilise TLS sur toutes les interfaces servies. Le chiffrement au repos relève de la couche de base de données et de volumes; il dépend donc de la configuration de son exploitant. Sur votre propre matériel, c'est vous; sur les instances hébergées, c'est nous. Les mots de passe sont stockés uniquement sous forme de hachages salés conçus pour les mots de passe; les jetons de session sont stockés uniquement sous forme d'empreintes, de sorte qu'une ligne de session stockée n'est pas un identifiant utilisable.

Rien ne communique avec nos serveurs : aucune télémétrie, aucune requête de licence, aucun appel à un tiers dans le parcours de connexion. La même version fonctionne en environnement isolé sous licence d'entreprise.

Comment les changements sont testés avant leur livraison

Voici ce que chaque version doit réussir avant sa livraison. Chaque version doit réussir l'intégralité de la suite de conformité de 280 vérifications de better-auth et les 14 parcours d'acceptation de bout en bout sur une instance en service; les résultats actuels sont datés du 2026-07-25 et servis à /certification, lisibles par machine, depuis le moteur en cours d'exécution. Un changement qui modifie ce que l'API retourne échoue à cette vérification avant d'atteindre qui que ce soit.

Au-delà de la conformité, notre test d'intrusion interne est documenté et rejoué sans intervention humaine : chaque nuit, une suite de sondes monte une instance jetable et reteste les comportements de sécurité établis par ce test, de la résistance à l'énumération et des clôtures de jetons à la révocation des sessions lors d'une réinitialisation de mot de passe et au bridage des tentatives du second facteur. C'est un test interne, nommé ainsi à dessein : il attrape une régression la nuit même où elle est livrée; il n'est pas une assurance indépendante.

Qui peut accéder à votre déploiement

Hébergé : l'inscription crée l'instance automatiquement. Les exploitants de la plateforme peuvent accéder à l'instance qu'ils exploitent pour vous; nous le précisons ici plutôt que de vous le laisser découvrir plus tard. L'accès exige des identifiants, est journalisé et se limite à l'exploitation du service.

Sur votre propre matériel : nous ne pouvons pas accéder à votre déploiement. Il n'y a ni chemin d'administration à distance, ni connexion de retour vers nous, ni mécanisme dans le moteur qui nous laisse entrer. Le soutien se fait avec vous, à partir des éléments que vous choisissez de partager.

Dans le produit, l'API d'administration suit les mêmes règles. Elle est protégée par un identifiant d'exploitation propre à l'instance, comparé en temps constant. Une organisation peut aussi détenir un identifiant d'administration délégué, limité à son propre locataire et à une courte liste explicite d'opérations autorisées; chaque route d'administration hors de cette liste refuse l'identifiant délégué avant l'exécution de tout gestionnaire, et cet ensemble de refus est imposé par une matrice de tests couvrant chaque route et méthode, pas par un examen. La délégation ne permet pas l'élévation : un identifiant délégué n'accorde jamais d'autorité qu'il ne détient pas lui-même, et l'autorité ne s'élargit jamais dans une chaîne de délégation. Les identifiants sont liés à leur locataire à l'émission, pas déduits de la requête, et une requête entre locataires est refusée sans révéler si la cible nommée existe.

Si nous avons un incident

Si nous déterminons qu'un incident de sécurité de notre côté touche vos données, nous vous en informons dans les 72 heures suivant cette détermination, avec ce que nous savons, ce que nous avons fait et ce que nous recommandons. Les objectifs contractuels de réponse supplémentaires figurent dans les accords signés; ce délai est l'engagement minimal que nous publions pour tous.

Sous-traitants

Sur votre propre matériel sous licence d'entreprise : aucun. Rien ne quitte votre infrastructure.

Pour le service hébergé et ce site Web, les parties qui traitent le trafic ou les données sont : Hetzner (calcul et stockage des instances, UE), Cloudflare (DNS et acheminement des courriels entrants), Resend (relais de courriels transactionnels sortants) et Stripe (traitement des paiements et facturation des abonnements). Le paiement est hébergé par Stripe : vos données de carte vont à Stripe et ne passent jamais par nos systèmes. La liste ne change qu'avec un avis sur cette page.

Ce que nous refusons de faire

C'est dans l'accès des agents qu'un fournisseur d'identité est le plus tenté de rendre service. Voici les cas où Signet refuse plutôt, et chacun est un refus qu'une personne chargée d'un examen peut tester, pas une posture que nous décrivons.

Ce que nous ne revendiquons pas

Demandez-nous plutôt ce que nous testons réellement : les attestations de conformité ci-dessus sont réelles, datées et vérifiables sur une instance en cours d'exécution. Quand une ligne de cette liste change, le changement vient avec sa pièce justificative, pas avant.