Politique de signalement de vulnérabilités — WeInspect
Version v1.0 — 2026-05-04 Accompagnée d'un fichier public /.well-known/security.txt (RFC 9116).
Si vous avez découvert une faille de sécurité dans WeInspect, on veut le savoir avant que quelqu'un d'autre ne s'en serve. Cette page vous explique comment nous le dire de manière sécurisée, comment on va vous répondre, ce qu'on autorise, et ce qu'on ne tolère pas.
En clair
✓ On lit chaque rapport, dans les 24h ouvrées.
✓ On répare en priorité.
✓ On ne vous poursuit pas si vous avez agi de bonne foi.
✓ On vous crédite publiquement (si vous le voulez) dans le hall of fame.
✗ On ne paie pas de bug bounty financier pour l'instant
(équipe trop petite — ça viendra avec la croissance).
Comment nous signaler
Canal préféré — courriel chiffré
À : security@ouiinspect.ca
Sujet : [SECURITY] Brève description de la vulnérabilité
Clé PGP : disponible sur demande à security@ouiinspect.ca
Si vous n'avez pas de PGP, courriel non chiffré accepté — mais évitez d'inclure des PoC trop sensibles dedans, on vous enverra la clé pour les détails.
Canal alternatif — formulaire
Si vous préférez : <https://ouiinspect.ca/transparence/securite/signaler> — formulaire chiffré côté client, livré directement au DPO et au tech lead, sans transit par helpdesk.
Ce qu'on aimerait recevoir
- Description claire de la vulnérabilité
- Étapes de reproduction (PoC, captures, vidéos si utile)
- Impact estimé (qui, quoi, comment grave)
- Vos coordonnées (courriel, optionnel pseudonyme pour crédit)
- Préférence de divulgation (immédiate / coordonnée 90j / privée)
Comment on vous répond
| Étape | Délai cible | |---|---| | Accusé de réception | < 24h ouvrées | | Triage initial (sévérité, scope) | < 72h ouvrées | | Plan de correction communiqué | < 7 jours ouvrés (sauf complexité exceptionnelle) | | Déploiement correctif | Selon sévérité — voir ci-dessous | | Confirmation à votre intention | Dans les 7j post-déploiement | | Crédit public (si choisi) | À la prochaine release |
Délais correctifs cibles (Service Level Objective)
| Sévérité | Critère | SLO correctif | |---|---|---| | Critique | RCE, accès massif données users, contournement auth | < 24h | | Élevée | Faille RLS exposant données spécifiques, escalation privilèges | < 72h | | Moyenne | XSS auth requis, IDOR limité, leak metadata non sensible | < 14j | | Faible | Mauvaise pratique, headers manquants, info disclosure mineure | < 30j | | Informationnel | Bonne pratique optionnelle, ergonomie sécurité | À discuter |
Programme de divulgation responsable
Champ d'application — couvert
- Domaine
ouiinspect.caet sous-domaines - Application web
app.ouiinspect.ca - API
api.ouiinspect.ca - Application mobile WeInspect (iOS App Store + Google Play)
- Endpoints documentés
Hors champ d'application
- Sites tiers (Stripe, Supabase, Anthropic, OpenAI) — signaler à eux directement
- Phishing, ingénierie sociale contre nos employés
- Attaques DDoS volumétrique
- Vulnérabilités physiques (locaux)
- Bugs de design ou ergonomie sans implication sécurité
- Vulnérabilités dans dépendances tierces (à signaler upstream ; on déploie patches dès qu'ils existent)
Règles de bonne foi
Nous n'engagerons pas de poursuites contre tout chercheur ayant agi de bonne foi et respectant les règles suivantes :
- Ne pas exfiltrer plus que nécessaire pour démontrer la faille (1-2 enregistrements suffisent à prouver l'accès, pas besoin de dump complet)
- Ne pas modifier ni détruire de données
- Ne pas dégrader le service (DDoS, surcharge intentionnelle)
- Ne pas partager publiquement la vulnérabilité avant qu'on ait corrigé (divulgation coordonnée 90 jours par défaut, négociable)
- Ne pas accéder aux données d'autres utilisateurs ; tester sur votre propre compte
- Respecter la vie privée des utilisateurs et de l'équipe WeInspect
- Ne pas exiger de paiement comme condition de divulgation (ce serait de l'extorsion, pas de la recherche)
Si vous respectez ces règles, on s'engage à :
- Ne pas porter plainte au criminel (Code criminel art. 342.1, 430)
- Ne pas porter plainte au civil (recours en dommages)
- Vous défendre publiquement si un tiers vous attaque pour avoir signalé en respectant ces règles
Crédit public — Hall of Fame
Page /transparence/securite/hall-of-fame liste, par ordre chronologique :
2026-XX-XX — [Nom ou pseudonyme] : XSS authentifié dans /tools/report
2026-XX-XX — [Nom ou pseudonyme] : Faille RLS exposant findings draft
...
Si vous préférez rester anonyme, dites-le ; on liste alors "Chercheur anonyme — date".
Bug bounty financier
Pas pour l'instant. WeInspect est une petite équipe pré-revenu (lancement public 2026-11-04). On reviendra avec un programme bounty financier dès que la marge le permet — typiquement 6-12 mois après lancement.
En attendant :
- Crédit public dans le Hall of Fame
- Mention LinkedIn / Twitter avec votre accord
- Lettre de recommandation pour CV (cybersécurité, postuler audit, etc.)
- Goodies WeInspect (t-shirt, hoodie) pour vulnérabilités matérielles
Si vous faites ça pour gagner votre vie : on respecte, mais ce n'est pas le bon endroit pour l'instant. Revenez en 2027.
Communication post-correction
Pour chaque vulnérabilité matérielle corrigée :
- Notification du chercheur : "voici ce qu'on a fait, voici quand, merci"
- Note de version interne : changelog product (sans détails exploitables)
- Post-mortem public dans
/transparence/incidents/sec-AAAA-MM-DD-NNNaprès période de grâce 30j (laisser users mettre à jour mobile) - Notification users si applicable : si la vulnérabilité a pu être exploitée et a touché des données, on suit la procédure incident (voir
incident-response-playbook.md)
Fichier /.well-known/security.txt
Conformément à RFC 9116, on publie un fichier standardisé à https://ouiinspect.ca/.well-known/security.txt :
Contact: mailto:security@ouiinspect.ca
Contact: https://ouiinspect.ca/transparence/securite/signaler
Acknowledgments: https://ouiinspect.ca/transparence/securite/hall-of-fame
Preferred-Languages: fr, en
Canonical: https://ouiinspect.ca/.well-known/security.txt
Policy: https://ouiinspect.ca/transparence/securite
Hiring: https://ouiinspect.ca/carrieres
Expires: <recalculé automatiquement à chaque requête : date du jour + 12 mois>
Le champ Expires est recalculé automatiquement (date du jour + 12 mois, UTC) par le Route Handler à chaque requête — aucun renouvellement manuel requis (conformité RFC 9116 : l'Expires reste toujours dans le futur).
Historique des versions
| Version | Date | Changement | |---|---|---| | v1.0 | 2026-05-04 | Politique initiale |
Hall of Fame (ouvert)
Aucun chercheur encore — vous pourriez être le premier.