La sécurité n’est pas une fonctionnalité ajoutée tardivement. C’est la façon dont la plateforme est construite. Cette page décrit les mesures qui protègent votre compte et vos données, ce que vous pouvez faire de votre côté, et comment signaler une vulnérabilité si vous en trouvez une.
Comment nous protégeons vos données
HTTPS partout
Tout le trafic entre votre appareil et nos serveurs est chiffré en TLS 1.2 ou supérieur. Les requêtes HTTP simples sont automatiquement redirigées vers HTTPS. HSTS (HTTP Strict Transport Security) est appliqué pour que votre navigateur ne retombe jamais sur une connexion non sécurisée.
Sécurité des mots de passe
Les mots de passe ne sont jamais stockés en clair. Nous utilisons bcrypt avec un facteur de coût élevé (cost 12) pour hacher chaque mot de passe avant qu’il n’atteigne notre base. Même en cas de compromission de la base, les mots de passe resteraient hors de portée d’un calcul réaliste.
Jetons de session de courte durée
L’authentification repose sur des JSON Web Tokens (JWT). Les jetons d’accès expirent en 15 minutes ; les jetons de rafraîchissement en 7 jours. Les deux sont stockés exclusivement dans des cookies HttpOnly, Secure, SameSite=Strict - inaccessibles au JavaScript, ce qui vous protège des attaques XSS.
Authentification multifacteur
Nous proposons des codes à usage unique (OTP) par e-mail comme second facteur à la connexion. Activer la MFA réduit fortement le risque de compromission même si votre mot de passe fuite.
Limitation de débit
Tous les points d’API sont limités en débit via un throttling adossé à Redis. Les points de connexion et de réinitialisation de mot de passe ont des limites plus strictes, pour prévenir les attaques par force brute et par bourrage d’identifiants.
Assainissement des entrées
Chaque donnée fournie par un utilisateur est validée par des DTO class-validator côté serveur et assainie par un middleware global avant traitement. Cela protège des attaques par injection et des XSS.
Sécurité de la base de données
Notre base MongoDB est chiffrée au repos (AES-256) et en transit (TLS). Un contrôle d’accès par rôles garantit que seul le compte de service applicatif peut lire ou écrire. L’accès administrateur exige une authentification multifacteur et une liste d’adresses IP autorisées.
Gestion des secrets
Tous les secrets - clés d’API, identifiants de base de données, clés de signature JWT - sont gérés via des variables d’environnement et des coffres de secrets CI/CD. Ils ne sont jamais écrits en dur dans le code ni versionnés.
En-têtes de sécurité
Notre serveur d’API utilise Helmet.js pour définir une Content-Security-Policy stricte, ainsi que X-Content-Type-Options, X-Frame-Options et Referrer-Policy. Notre frontend Next.js applique des en-têtes correspondants via next.config.js.
Audit des dépendances
Nous figeons explicitement toutes les versions de paquets et lançons des audits de vulnérabilités automatisés (pnpm audit) à chaque build. Les correctifs de sécurité critiques sont appliqués sous 48 heures après divulgation.
Ce que vous pouvez faire
- Utilisez un mot de passe fort et unique, que vous ne réutilisez sur aucun autre service.
- Activez l’authentification multifacteur (MFA) dans les paramètres de votre compte.
- Méfiez-vous des e-mails d’hameçonnage. Nous ne vous demanderons jamais votre mot de passe par e-mail ou message.
- Gardez votre application et votre appareil à jour pour recevoir les correctifs de sécurité.
- Déconnectez-vous après usage sur un appareil partagé ou public.
Divulgation responsable
Si vous pensez avoir trouvé une vulnérabilité, prévenez-nous avant d’en parler à quiconque.
Écrivez à support@toofreshtowaste.com avec pour objet Security Vulnerability Report. Décrivez la vulnérabilité en détail - étapes de reproduction, impact potentiel, captures d’écran ou code de démonstration à l’appui.
Ne divulguez pas publiquement la vulnérabilité avant que nous ayons eu une occasion raisonnable d’enquêter et de corriger (généralement 90 jours).
Nos engagements
- Nous accuserons réception de votre signalement sous 3 jours ouvrés.
- Nous vous tiendrons informé pendant l’investigation et la correction.
- Nous n’engagerons aucune action en justice contre les chercheurs qui signalent de bonne foi et respectent cette politique.
- Nous créditons publiquement les personnes qui signalent (avec leur accord) une fois le correctif déployé.
Hors périmètre
- Attaques par déni de service (DoS/DDoS)
- Ingénierie sociale ou hameçonnage de nos employés
- Attaques nécessitant un accès physique à l’appareil d’un utilisateur
Contact sécurité
Too Fresh To Waste - équipe sécurité. Écrivez-nous à support@toofreshtowaste.com.