Merci de prendre la sécurité de ce projet au sérieux. Ce document décrit comment signaler une vulnérabilité de manière responsable.
Ce projet est open source et en évolution active. Les correctifs de sécurité sont appliqués sur la branche main uniquement.
| Version | Supportée |
|---|---|
main |
✅ |
| autres | ❌ |
NE PAS ouvrir une issue publique sur GitHub pour une vulnérabilité de sécurité.
À la place, envoyez un courriel détaillé à : [email protected]
Avec en objet : [SECURITY] Constructo AI - <courte description>
Incluez si possible :
- Description de la vulnérabilité et de son impact potentiel
- Étapes pour la reproduire (proof of concept apprécié)
- Version / commit affecté
- Toute information sur la divulgation responsable (date limite souhaitée, etc.)
- Vos coordonnées si vous souhaitez être crédité
| Étape | Délai cible |
|---|---|
| Accusé de réception | sous 72 heures |
| Évaluation initiale | sous 7 jours |
| Correctif (si confirmé) | selon criticité (1-30 jours) |
| Communication publique | après correctif déployé |
Nous remercions publiquement les chercheurs en sécurité qui signalent des vulnérabilités de manière responsable (sauf demande contraire). Aucune compensation financière n'est offerte pour le moment.
Inclus dans le périmètre :
- Code source dans ce dépôt (ERP_REACT, MOBILE_REACT, SEAOP_REACT, modules Python partagés)
- Vulnérabilités dans la logique d'authentification, d'autorisation, multi-tenant
- Injections (SQL, command, path traversal), XSS, CSRF, SSRF
- Fuites de secrets / credentials
- Failles d'isolation entre tenants
Hors périmètre :
- Instances tierces (forks, déploiements de tiers) — contactez l'opérateur de l'instance
- Attaques nécessitant un accès physique au serveur
- DoS volumétrique (DDoS)
- Vulnérabilités dans des dépendances tierces (à reporter au mainteneur de la dépendance)
- Configurations de déploiement spécifiques à un opérateur (CORS, TLS, etc.)
- Bugs hors sécurité — ouvrez une issue publique pour ceux-ci
Ce projet a fait l'objet d'audits automatisés multi-passes couvrant :
- Secrets hardcodés (clés API, mots de passe, tokens)
- Authentification (JWT, sessions, bcrypt, timing attacks)
- Injections SQL (paramétrage, identifiants)
- Headers HTTP de sécurité (HSTS, CSP, X-Frame-Options, etc.)
- SSRF (validation des URLs sortantes)
- Isolation multi-tenant
- Cryptographie (random vs secrets, HMAC, hashing)
Aucun audit de pénétration humain professionnel n'a encore été effectué. Les utilisateurs déployant cette plateforme en production sont encouragés à :
- Effectuer leur propre audit de sécurité avant mise en production
- Configurer correctement les variables d'environnement (voir
.env.example) - Activer un monitoring d'erreurs (Sentry — déjà câblé)
- Maintenir les dépendances à jour (
pip-audit,npm audit) - Activer la MFA sur tous les comptes admin de la plateforme
- HTTPS obligatoire en production (le code force
secure=Truesur les cookies hors développement) - Définir tous les secrets via variables d'environnement (jamais en dur)
- Activer
ENVIRONMENT=productionpour bloquer les comportements de développement - Configurer
ALLOWED_ORIGINSstrictement (pas de wildcard*aveccredentials) - Backups réguliers de la base de données
- Rotation périodique des secrets JWT
- Surveillance des logs (échecs d'auth, rate limits, erreurs 5xx)
Liste des chercheurs ayant contribué (avec leur permission) :
- Aucun pour le moment
Contact : [email protected] · 514-820-1972 · https://constructoai.ca