Programme Bug Bounty

Capgo s'engage pour la sécurité et la transparence. L'ensemble de nos code est en open source, et nous invitons les chercheurs en sécurité à nous aider à identifier les vulnérabilités de notre codebase.

Code en open source

Chaque dépôt de l'organisation Capgo est en open source. Vous pouvez examiner, auditer et contribuer à notre code.

Organisation GitHub : github.com/Cap-go

Conditions de validité des rapports

Pour être éligible au programme Bug Bounty, votre rapport doit remplir TOUTES les conditions suivantes :

• Vous devez identifier le fichier et le numéro de ligne exacts dans notre dépôt GitHub où se trouve la vulnérabilité
• Votre rapport doit être soumis via la GitHub Security Advisory du dépôt concerné
• Vous devez inclure une description claire de la vulnérabilité et de son impact potentiel
• Vous devez fournir des étapes de reproduction pour démontrer le problème

Temps de réponse et respect

Nous sommes sympas et nous rémunérons les rapports valides, mais nous ne pouvons pas travailler avec des personnes qui ne respectent pas notre temps. Merci de garder une communication calme et de respecter les règles de ce programme.

• Nous répondons aux rapports de sécurité et aux failles sous 24 à 72 heures.
• Ne nous spammez pas. Plus de trois e-mails dans la même journée sont considérés comme du spam et seront bloqués.
• Nous ne rémunérons pas les rapports qui ignorent ces règles ou qui relèvent du spam.
• Seuls les rapports dans le périmètre qui respectent ce programme bug bounty sont acceptés ; tout autre envoi pourra être bloqué.
• Ne demandez pas de suivi du type « avez-vous vérifié ? » ou questions similaires. Une fois que nous avons confirmé la réception de votre rapport, cela suffit. Il reste ensuite un travail important à accomplir, et la préparation d'une pull request peut prendre plusieurs jours.

Comment signaler un bug

1. Accédez au dépôt concerné sur GitHub
2. Cliquez sur l'onglet « Security »
3. Cliquez sur « Report a vulnerability » pour créer un nouvel avis de sécurité
4. Indiquez le chemin exact du fichier et le(s) numéro(s) de ligne de la vulnérabilité
5. Fournissez des étapes détaillées pour reproduire le problème et expliquez l'impact sur la sécurité

Hors périmètre

• Les rapports sans références précises aux lignes de code dans GitHub
• Les rapports non soumis via GitHub Security Advisory
• Les vulnérabilités théoriques sans preuve de concept
• Bugs dans des plateformes, dépendances ou services tiers que Capgo ne peut pas corriger directement (signalez-les en amont, par exemple à Supabase).
• Les tentatives d'ingénierie sociale ou de phishing
• Les attaques par déni de service
• Les rapports de SSRF ou de DNS spoofing ciblant les webhooks ou l'aperçu du site web. Ces fonctionnalités fonctionnent sur une infrastructure serverless et ne peuvent pas être utilisées pour atteindre l'infrastructure privée de Capgo, elles ne sont donc pas exploitables dans notre environnement.
• La configuration de l'application code ou du projet appartenant à l'utilisateur et que Capgo ne possède pas, ne déploie pas et ne contrôle pas, incluant des fichiers tels que capacitor.config.ts, config.capacitor.ts, le code source code, et les paramètres spécifiques à l'environnement.
• L'accès aux fichiers de bundle Capgo ou la preuve que les fichiers de bundle peuvent être téléchargés. Les fichiers de bundle sont des assets web publics, les utilisateurs en sont informés, et leur accès n'est pas considéré comme une violation de données.
• Les endpoints de plugin Capgo ou API non authentifiés qui sont intentionnellement publics par conception — y compris le paramètre channel_self et les endpoints update/stats ne nécessitant pas de clé API — ne sont pas des vulnérabilités. Ne les signalez pas comme telles.
• Un uploader ou une UI qui étiquette à tort le chiffrement des bundles servis via external_url ne constitue pas une vulnérabilité Capgo (le chiffrement des bundles hébergés en externe échappe au contrôle de Capgo).

Supabase et les services tiers

Si la cause racine est un bug de la plateforme ou d'un service Supabase, signalez-l’à Supabase, pas à Capgo. Si la logique, le SQL, le RPC, la politique RLS, l'Edge Function ou la configuration vulnérable a été créée ou choisie par Capgo et que nous pouvons la corriger dans notre projet, elle entre dans le périmètre, même si c'est Supabase qui sert l'endpoint. Pour les découvertes concernant le comportement de Supabase lui-même, incluez un cas reproductible et le réglage ou la modification de configuration Supabase exacte qui l'empêche dans un projet configuré comme le nôtre.

Exemples

Limitations connues de Supabase Auth (déjà signalées)

Certaines découvertes sont signalées de manière répétée et sont causées par les paramètres par défaut de Supabase Auth ou par le comportement de la plateforme plutôt que par Capgo code. Nous ne les examinons que si elles peuvent être reproduites dans un projet de démo Supabase partagé, configuré comme le nôtre, et si la correction consiste en un changement de configuration côté Supabase qui ne nécessite pas de modifier les règles de sécurité Capgo. Si la correction nécessite de modifier le SQL, les RPC, les politiques RLS, les fonctions ou la logique applicative appartenant à Capgo, signalez-le-nous car cela entre dans le périmètre.

• Fournissez un cas reproductible et identifiez la correction exacte : soit le changement de paramètre/config Supabase qui résout un problème de comportement Supabase, soit l'objet code/config appartenant à Capgo qui doit être modifié.
• Le comportement de la vérification par e-mail suit les paramètres de votre projet Supabase Auth (par exemple, si la confirmation par e-mail est désactivée ou si l'authentification basée sur la capture est utilisée).
• Les flux de mise à jour de mot de passe et de récupération de compte peuvent ne pas toujours exiger la saisie de l'ancien mot de passe ou une nouvelle vérification si Supabase Auth est configuré ainsi.
• Si le problème figure dans cette liste mais que vous pouvez démontrer une correction concrète côté Supabase dans le projet fourni ou un défaut de sécurité concret appartenant à Capgo, nous pourrons l'inclure dans le périmètre.

Pour toute question concernant notre programme Bug Bounty, veuillez nous contacter via nos GitHub Security Advisories.