Sécurité & Confiance

La sécurité réside dans Postgres, pas dans la discipline applicative. Chaque produit active la Row-Level Security sur chaque table, dès le premier jour.

• Les produits multi-locataires (AdminOS) imposent l'isolation en comparant le tenant_id du JWT au tenant_id de la ligne dans une politique RLS sur chaque table — le tenant_id est toujours résolu côté serveur à partir du jeton authentifié, jamais accordé de confiance depuis le client.
• La clé de rôle de service privilégiée est confinée aux chemins exclusivement côté serveur (webhooks, cron, facturation) et n'atteint jamais le navigateur ; les lectures/écritures standard s'exécutent sous le contexte RLS de l'utilisateur.
• Lectures publiques limitées aux contenus publiés, mises à jour réservées à l'auteur et soft-delete (deleted_at) constituent la posture RLS par défaut — les enregistrements ne sont jamais supprimés définitivement.

Chaque webhook entrant est vérifié cryptographiquement avant de pouvoir toucher aux données — avec comparaison à temps constant et, le cas échéant, une protection contre le rejeu.

• Meta WhatsApp Cloud API : HMAC-SHA256 sur le corps brut (x-hub-signature-256), comparé via une vérification d'égalité à temps constant ; une signature invalide donne un 401.
• PayFast ITN : signature MD5 plus une vérification de l'IP source avant tout changement d'état d'un plan ou d'une commande.
• Appels internes de système à système (store ↔ engine) : clé Bearer + HMAC-SHA256(corps) en sortie ; signature sur timestamp.body en entrée, avec une fenêtre de rejeu de cinq minutes.
• Paystack (True Access) : vérification HMAC-SHA512 sur le webhook de paiement.

Les surfaces publiques sont filtrées avant d'atteindre la base de données ou un LLM, afin de borner le coût et les abus.

• Protection en périphérie (Arcjet) avec des règles bot, débit et bouclier sur le produit destiné aux étudiants.
• Limiteurs à fenêtre glissante Upstash sur les chemins API, webhook, IA et onboarding — mis en cache en singletons pour éviter de rouvrir des connexions Redis.
• Budgets d'IA par point de terminaison et limites quotidiennes de jetons par plan, appliqués dans Redis avec un 429 en cas d'épuisement.

Un numéro WhatsApp public est un tuyau ouvert vers un modèle de langage. Les entrées non fiables sont assainies dès l'ingestion, avant même d'être stockées.

• Les messages entrants passent par un assainisseur (16–17 motifs d'injection + un plafond de 2 000 caractères) avant toute écriture en base — de sorte qu'aucune charge malveillante n'est persistée ni rejouable.
• La configuration fournie par l'administrateur passe par un assainisseur distinct et plus strict pour empêcher l'empoisonnement de cache inter-locataires.
• Les prompts système sont isolés dans le paramètre système du modèle avec une mise en cache éphémère, de sorte que le contenu utilisateur injecté ne peut pas corrompre un prompt mis en cache.

Les jetons restent hors du navigateur, les secrets restent hors du bundle, et chaque réponse embarque des en-têtes durcis.

• Les sessions utilisent des cookies HTTP-only — aucun jeton d'authentification dans le localStorage ; OAuth fonctionne via PKCE.
• Les secrets de rôle de service, de modèle et de webhook ne sont jamais exposés en NEXT_PUBLIC ni journalisés ; un inventaire documenté attribue un responsable de rotation.
• En-têtes de sécurité audités sur toutes les routes : HSTS (avec preload), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, une Content-Security-Policy et une Permissions-Policy restrictive.

Les systèmes sensibles conservent une trace inviolable de ce qui s'est passé — par construction, pas par convention.

• Le journal d'audit a ses privilèges UPDATE et DELETE révoqués au niveau de la base de données — même le rôle de service ne peut pas altérer une entrée.
• Les enregistrements financiers (contributions, versements, prêts) portent des numéros de reçu uniques et une référence recorded_by ; un état avant/après immuable est capturé à chaque modification.
• Les ID des webhooks entrants sont stockés en UNIQUE pour dédupliquer les nouvelles tentatives du fournisseur.