Sécurité de la plateforme

Cette page est maintenue par l'équipe Taxelyo et décrit les mesures de sécurité réellement appliquées sur la plateforme. Elle ne constitue pas une certification indépendante.

1. Chiffrement

• Chiffrement au repos AES-256 (base de données + stockage de fichiers — buckets newsletter-exports et b2b-quotes privés).
• Chiffrement en transit TLS 1.3 sur tous les domaines (*.taxelyo.com).
• Secrets applicatifs (clés Stripe, signatures HMAC, clés de chiffrement newsletter) stockés hors-dépôt et injectés au runtime.

2. Contrôle d'accès — Row-Level Security

Chaque table contenant des données utilisateur a RLS activé, avec des politiques explicites par rôle (anon, authenticated, service_role).

• Données financières (profiles.monthly_revenue, subscriptions.stripe_*) : aucun accès anon, lecture limitée au propriétaire (auth.uid() = user_id).
• Rôles admin : stockés exclusivement dans org_members (jamais sur profiles) et vérifiés via une fonctionSECURITY DEFINER non-récursive.
• Audit logs (security_audit_log, consent_audit_logs, newsletter_compliance_log) : insertions service_role uniquement, mutations bloquées par trigger.
• Realtime : aucune table contenant PII ou données financières n'est publiée dans supabase_realtime. Les UIs utilisent du polling ou des RPC SECURITY DEFINER.

3. Authentification

• Connexion par Magic Link exclusivement (pas de mot de passe à fuiter).
• Sessions JWT signées, rotation automatique.
• Vérification serveur du rôle admin pour chaque endpoint sensible (jamais en confiance dans le client).

4. Journal d'audit

Les accès suivants sont journalisés dans security_audit_log (immuable, lecture admin uniquement) :

• Chaque appel à get_referral_leaderboard() (détection d'exfiltration par scraping).
• Chaque endpoint email (consent export, newsletter export, contact router) avec IP, user-agent, nombre de lignes retournées.
• Tentatives d'accès refusées (outcome = 'denied') — utiles pour détecter les sondes d'API.

5. Tests automatisés & CI

• e2e/rls-policies.spec.ts — vérifie avant chaque déploiement qu'un client anonyme ne peut pas lire profiles,subscriptions, contact_requests, newsletter_subscribers ni email_captures.
• scripts/check-security-definer.mjs — gate CI qui échoue si une nouvelle fonction SECURITY DEFINER non documentée apparaît.
• Lighthouse mobile + Core Web Vitals + accessibilité (a11y) — checks par PR.
• Audit RLS automatique via le linter Supabase à chaque migration.

6. Monitoring & réponse à incident

• Page publique /status avec health checks 5 min.
• Dead-letter queue surveillée (/admin/dlq) avec règles d'escalade.
• Alertes multi-canal (in-app + email + webhook HMAC) avec déduplication par sévérité.
• Snapshots de readiness toutes les 15 min pour le pipeline d'export newsletter.

7. Hébergement & sous-traitants

• Base de données et stockage : Supabase (UE).
• Paiements : Stripe (UE, PCI DSS Level 1).
• Emails transactionnels : Resend (clauses contractuelles types pour transferts hors UE).

8. Signaler une vulnérabilité

Email dédié : security@taxelyo.com. Politique de divulgation responsable : réponse sous 48h ouvrées, correctif déployé sous 7 jours pour les vulnérabilités critiques.