Aller au contenu principal

📐 Sécurité & Conformité

Modèle de sécurité​

Couches de protection​

Utilisateur
    ↓
[HTTPS/TLS] — transport chiffré
    ↓
[Supabase Auth] — JWT + session
    ↓
[Edge Functions] — validation des entrées
    ↓
[PostgreSQL RLS] — isolation par user_id
    ↓
[Données] — stockage chiffré at-rest (Supabase)

Authentification​

JWT Supabase​

  • Tokens JWT signés par Supabase, durée de vie configurable
  • Auto-refresh via autoRefreshToken: true
  • Stockage dans localStorage avec persistSession: true
  • Révocation possible depuis le dashboard Supabase

Providers supportés​

ProviderStatut
Email / Mot de passe✅ Actif
Google OAuth✅ Actif
GitHub🗓️ Prévu Q2 2026
SSO SAML/OIDC🗓️ Prévu Q4 2026 (Enterprise)

Dette technique — verify_jwt = false​

Les Edge Functions acceptent actuellement les requêtes sans JWT valide. Migration prévue Q2 2026 lors du déploiement de l'API v1.

Row Level Security (RLS)​

Le RLS PostgreSQL garantit l'isolation complète des données :

  • Chaque utilisateur ne peut lire, modifier et supprimer que ses propres données
  • La politique s'applique via auth.uid() = user_id
  • Impossible de contourner même avec un accès direct à la DB
  • community_reports : lecture partagée, écriture isolée par reporter_id

Voir le détail complet dans DATABASE.md.

Gestion des clés API​

Clés utilisateur (frontend)​

Les clés API (IPQualityScore, AbuseIPDB, VirusTotal) saisies dans les Paramètres sont stockées dans localStorage du navigateur.

  • Elles ne transitent que lors des appels à analyze-email-headers
  • Elles ne sont jamais stockées dans la base de données Supabase
  • Elles ne sont jamais transmises à des tiers autres que le service concerné

Secrets serveur (Edge Functions)​

Les secrets serveur sont configurés dans le dashboard Supabase et accessibles uniquement depuis les Edge Functions (variable d'environnement Deno).

Validation des entrées​

Côté frontend​

  • Zod pour la validation des formulaires (React Hook Form)
  • Nettoyage des inputs avant envoi aux Edge Functions

Côté Edge Functions​

  • Validation de présence des champs obligatoires
  • Rejet avec HTTP 400 si données manquantes ou invalides
  • Normalisation des numéros de téléphone avant matching

⚠️ La validation côté serveur est partielle dans le MVP. Renforcement prévu Q2 2026.

Limitation de requêtes​

Système de crédits (frontend)​

  • 5 analyses/jour par utilisateur
  • Stocké en localStorage (contournable — dette technique)
  • Migration vers table DB prévue Q2 2026 (incontournable)

Rate limiting API (prévu Q2 2026)​

  • Table user_quotas en PostgreSQL
  • 100 req/min, 10 000/jour pour l'API v1
  • Réponse HTTP 429 si quota dépassé

Conformité RGPD​

Principes appliqués​

PrincipeImplémentation
MinimisationSeuls les headers email et numéros sont traités (pas les corps d'email)
FinalitéDonnées utilisées exclusivement pour l'analyse de sécurité
TransparenceDocumentation complète du traitement
IsolationRLS PostgreSQL + suppression en cascade
Hébergement souverainSupabase EU (France/Union Européenne)
Pas de reventeAucune donnée transmise à des tiers sans consentement
Droit à l'effacementSuppression compte → suppression cascade de toutes les données

Données traitées​

DonnéeFinalitéConservation
Adresse email (compte)AuthentificationDurée du compte
En-têtes emailAnalyse de sécuritéJusqu'à suppression manuelle
Numéros de téléphoneVérification ARCEPJusqu'à suppression manuelle
IP des emails analysésRéputation/sécuritéJusqu'à suppression manuelle

Données NON collectées​

  • Corps des emails (uniquement les headers)
  • Pièces jointes
  • Données de navigation (pas de cookies traceurs)
  • Données biométriques

Responsable du traitement​

Fondateur du projet BlocMail & BlocNumEtSMS
Contact : contact.seb205@gmail.com
DPO désigné : Q2 2026

Hébergement et souveraineté​

ComposantHébergeurLocalisation
FrontendLovable Cloud / VercelUE
Base de donnéesSupabase EUFrance / UE
Edge FunctionsSupabase DenoUE
AuthSupabase AuthUE

Sécurité des exports et webhooks​

  • Les exports (JSON, CSV, XML) sont générés côté client et téléchargés directement
  • Les webhooks n8n/Make ne sont déclenchés que par action explicite de l'utilisateur
  • Aucune donnée n'est transmise sans action volontaire
  • Les URLs de webhooks sont stockées localement (localStorage), non en DB

Roadmap sécurité​

PrioritéActionÉchéance
🔴 Critiqueverify_jwt = true sur les Edge FunctionsQ2 2026
🔴 CritiqueCrédits quotidiens en DB (incontournables)Q2 2026
🟠 Haute2FA / MFA pour comptes Premium/PMEQ2 2026
🟠 HauteRate limiting serveur (table user_quotas)Q2 2026
🟡 MoyenneAudit logs (journalisation actions RGPD)Q2 2026
🟡 MoyennePolitique de rétention auto (> 90 jours)Q3 2026
🟢 BasseChiffrement AES des exports CSV/JSONQ3 2026
🟢 BasseAudit de sécurité externe + certification ISO 270012027+

Liens de référence​