La sécurité, énoncée simplement.

Transport & authentification

• Entrée TLS uniquement. L'API écoute sur la boucle locale ; le seul point d'entrée public termine TLS, les clés bearer ne circulent donc jamais en clair.
• Clés hachées, affichées une fois. Hachages SHA-256 au repos ; le texte en clair n'est renvoyé qu'une seule fois, à la création ou à la rotation. Rotation et révocation sont instantanées.
• Isolation par espace de travail à chaque requête. Périmétrée dans la couche de persistance ; les lectures inter-locataires renvoient 404, pas 403.
• Limitation de débit par clé. Seaux de jetons dans Redis ; fail-open ou fail-closed est un choix d'exploitant.

Webhooks

• Charges signées. HMAC-SHA256 horodaté (X-Pauli-Signature) sur les octets exacts de la charge, si bien qu'une livraison capturée ne se rejoue que dans votre tolérance de vérification ; les rotations signent avec l'ancien et le nouveau secret pendant une fenêtre de recouvrement. X-Pauli-Event-Id déduplique.
• Gardes SSRF, deux fois. URLs de webhook en https uniquement, refusées quand elles résolvent vers du non-public (boucle locale, RFC 1918, lien-local, métadonnées cloud) à l'envoi, et revérifiées à la livraison contre le DNS rebinding. Toujours actif ; pas d'interrupteur.

Argent & intégrité des données

• Decimal de bout en bout. L'argent ne passe jamais par des flottants ; les montants de l'API sont des chaînes décimales exactes.
• Facturation exactement-une-fois, imposée par la base. Des index uniques partiels protègent facturations, débits et remboursements ; les relances et redistributions ne peuvent ni double-facturer ni double-créditer.
• Les paiements ne créditent que sur fonds confirmés. Les webhooks Stripe sont vérifiés en signature avec tolérance de rejeu ; un compare-and-swap de statut rend le crédit idempotent.
• Journal d'audit en append-only. Cycle de vie des clés, événements de jobs, facturation, décisions de conformité et échecs d'authentification, écrits dans la même transaction que l'action.

Exploitation

• Une seule source de vérité. Postgres détient tout l'état ; perdre la file ne perd ni jobs, ni résultats, ni argent.
• Traitement résistant aux crashs. Les workers réclament les jobs avec des bails et committent à chaque frontière de phase ; des balayages redérivent tout travail lâché par un processus mort.
• Sauvegardes vérifiées. Testées en restauration selon un calendrier (une sauvegarde non restaurée n'est pas une sauvegarde) ; des copies chiffrées partent hors hôte.
• Les erreurs ne divulguent jamais l'interne. Les corps 5xx ne portent qu'un code stable et un id de requête ; le détail reste dans les logs côté serveur.
• Page de statut publique. Hébergée hors de notre infrastructure sur status.pauli.xyz, pour rester joignable quand nous ne le sommes pas.

Posture de conformité

• Barrière de contrôle des exportations dans le routeur. Le matériel contrôlé n'est routé que vers des espaces de travail filtrés avec juridiction déclarée ; chaque refus est audité.
• Filtrage des parties interdites. Chaque décision de filtrage est auditée ; le routage la lit à chaque requête.

Signaler une vulnérabilité

Écrivez à hello@pauli.xyz avec les étapes de reproduction. Nous accusons réception sous deux jours ouvrés et n'engageons aucune action en justice contre la recherche de bonne foi.