Politique de securite

1. Principe directeur

La cybersecurite etant le coeur de metier de LuksMentis, notre exigence interne sur la securite du Service est elevee. Nous appliquons systematiquement les recommandations OWASP Top 10 (web) et OWASP API Security Top 10 (API).

Cette page documente les mesures concretement implementees a date. Les details techniques precis sont volontairement non-exhaustifs pour ne pas faciliter la tache d'eventuels attaquants ; le present document est revisable sur demande motivee (clients professionnels, audits).

2. Authentification

• Magic Link uniquement : aucune authentification par mot de passe. Elimination des risques de mot de passe faible, reutilise ou brute-force.
• Sign in with Apple : alternative MFA-native via le compte iCloud de l'utilisateur (sur iOS).
• Tokens JWT : emis par Supabase Auth, signature HS256, duree de vie 1h, refresh 7 jours.
• Session unique : 1 token de session UUID par compte. Connexion sur un nouvel appareil deconnecte les sessions precedentes (anti-partage de compte).

3. Chiffrement et confidentialite

• TLS 1.3 obligatoire : toute communication client-serveur. HSTS preload 2 ans (force HTTPS au niveau navigateur).
• Chiffrement au repos : base de donnees Supabase chiffree AES-256 (gere par Supabase).
• HMAC SHA256 : sur les webhooks internes (push critique LuksMentis -> Supabase) avec comparaison constant-time pour prevenir les timing attacks.
• Signature Stripe : verification de signature sur tous les webhooks Stripe (rejet en cas de signature invalide ou de timestamp obsolete).

4. Isolation des donnees

• Row Level Security (RLS) : activee sur toutes les tables sensibles avec politiques deny-by-default. Un utilisateur ne peut acceder qu'a ses propres donnees, meme en cas de compromission du token JWT (RLS impose la verification cote base de donnees).
• Service Role JAMAIS expose cote client : la cle d'administration Supabase reste exclusivement cote serveur (Vercel Edge Functions et Supabase Edge Functions).
• Append-only logs : les journaux d'audit sont proteges par trigger anti-UPDATE/DELETE au niveau base de donnees. Toute manipulation administrative est tracee de maniere irreversible.

5. Securisation des Edge Functions et APIs

• Bearer token machine : les fonctions d'ingestion vers la source LuksMentis sont authentifiees par token Bearer avec rotation. Token compare en constant-time (hmac.compare_digest) pour prevenir les attaques temporelles.
• Rate limiting : 60 requetes / minute / token cote source de contenu. Throttle Redis 1h sur les alertes critiques.
• Validation stricte : tous les inputs Edge Function passent par une validation Zod (TypeScript) ou Pydantic-equivalent. Aucune concatenation SQL directe.
• CSP strict : Content Security Policy avec whitelist explicite (Supabase + Stripe uniquement). Pas d'eval, pas d'inline JS dynamique.
• Frame-ancestors none : impossible d'encadrer le site dans une iframe (anti-clickjacking).

6. Securite operationnelle

• Dependabot : mise a jour automatique hebdomadaire des dependances avec PR de revue.
• Secret scan (gitleaks) : en CI sur chaque pull request pour detecter toute fuite accidentelle de secret.
• SAST (lint + tsc) : analyse statique du code obligatoire avant merge.
• Reviews de code : chaque modification du code passe par une pull request avec review humaine.
• Logs structures : pas de PII dans les logs applicatifs (emails masques, tokens redactes).

7. Sauvegardes

• Backups Postgres : automatiques via Supabase (point-in-time recovery sur la duree fonction du plan Supabase souscrit).
• Restauration testee : procedure de restauration documentee, testable a la demande.

8. Programme de divulgation responsable

Si vous identifiez une vulnerabilite de securite affectant le Service, nous vous remercions de nous en informer de maniere responsable :

• Contactez security@luksmentis.com avec une description detaillee
• Ne divulguez pas publiquement la vulnerabilite avant que nous ayons eu un delai raisonnable pour la corriger (90 jours recommandes)
• N'exploitez pas la vulnerabilite au-dela de ce qui est necessaire a sa demonstration
• Ne testez pas sur des comptes ou donnees autres que les votres

En contrepartie, nous nous engageons a :

• Accuser reception sous 5 jours ouvres
• Communiquer un calendrier de correction
• Creditrer publiquement le chercheur (avec son accord) une fois la vulnerabilite corrigee
• Ne pas engager de poursuites judiciaires contre les chercheurs agissant de bonne foi dans le cadre de cette politique

Aucun programme de bug bounty remunere n'est en place a date.

9. Notification de violation

Conformement a l'article 33 du RGPD, en cas de violation de donnees personnelles susceptible d'engendrer un risque pour les droits et libertes des personnes concernees, nous notifierons la CNIL dans les 72 heures suivant la prise de connaissance de la violation.

En cas de risque eleve, les utilisateurs concernes seront informes directement et dans les meilleurs delais (article 34 du RGPD).

10. Audit et evolution

Cette politique est revisee a chaque evolution majeure du Service et au minimum annuellement. Les utilisateurs et clients professionnels peuvent demander des informations complementaires ou des elements d'audit en contactant security@luksmentis.com.