Programme de récompense des bugs

Capgo s'engage à la sécurité et à la transparence. Tous nos code sont gratuits et ouverts, et nous accueillons les chercheurs de sécurité pour nous aider à identifier les vulnérabilités dans notre codebase.

Code Open Source

Tous les dépôts de l'organisation Capgo sont gratuits et ouverts. Vous pouvez examiner, auditer et contribuer à nos code.

Organisation GitHub : github.com/Cap-go

Exigences pour les Rapports Valides

Pour être éligible au programme Bug Bounty, votre rapport doit répondre à TOUTES les exigences suivantes :

• Vous devez identifier l'exacte fichier et le numéro de ligne dans notre dépôt GitHub où la vulnérabilité existe
• Votre rapport doit être soumis à travers l'avis de sécurité GitHub sur le référentiel pertinent.
• Vous devez inclure une description claire de la vulnérabilité et de son impact potentiel.
• Vous devez fournir des étapes réproubables pour démontrer le problème.

Temps de réponse et respect

Nous sommes amicaux et nous payons pour les rapports valides, mais nous ne pouvons pas travailler avec des personnes qui ne respectent pas notre temps. Veuillez garder la communication calme et suivre ce programme.

• Nous répondons aux rapports de sécurité et aux failles dans 24 à 72 heures.
• N'envoyez pas de spam. Plus de trois emails par jour est considéré comme du spam et sera bloqué.
• Nous ne payons pas pour les rapports qui ignorent ces règles ou sont du spam.
• Seuls les rapports pertinents qui suivent ce programme de bug bounty sont acceptés ; tout autre peut être bloqué.
• N'interrogez pas sur les mises à jour de statut comme « avez-vous vérifié ? » ou des questions similaires. Une fois que nous confirmons que nous avons reçu votre rapport, cela suffit. Après cela, il y a encore beaucoup de travail à faire, et la préparation d'une demande de tirage peut prendre plusieurs jours.

Comment signaler un problème

1. Navigatez vers le référentiel pertinent sur GitHub
2. Appuyez sur l'onglet « Sécurité »
3. Appuyez sur « Signaler une vulnérabilité » pour créer un nouveau avis de sécurité
4. Incluez l'emplacement de fichier exact et le numéro de ligne(s) où la vulnérabilité existe
5. Fournissez des étapes détaillées pour reproduire le problème et expliquez l'impact de sécurité

Hors du champ

• Les rapports sans références de ligne code exactes dans GitHub
• Les rapports non soumis à travers GitHub Security Advisory
• Les vulnérabilités théoriques sans preuve de concept
• Les bogues dans les plateformes tiers, les dépendances ou les services que Capgo ne peut pas fixer directement (signalez-les en amont, par exemple vers Supabase).
• Les tentatives d'ingénierie sociale ou de phishing
• Les attaques de refus de service
• Les rapports de SSRF ou de DNS spoofing contre les webhooks ou la prévisualisation du site. Ces fonctionnalités fonctionnent sur des infrastructures sans serveur et ne peuvent pas être utilisées pour atteindre l'infrastructure privée Capgo , ils ne sont donc pas exploitables dans notre environnement.
• La configuration de l'application code ou du projet que Capgo ne possède pas, n'expédie pas, ne contrôle pas, y compris les fichiers tels que capacitor.config.ts, config.capacitor.ts, les sources de l'application code et les paramètres spécifiques à l'environnement.
• Accès aux fichiers du bundle Capgo ou la preuve que les fichiers du bundle peuvent être téléchargés. Les fichiers du bundle sont des actifs web publics, les utilisateurs sont informés de cela et l'accès à eux n'est pas considéré comme une violation de données.
• Les points de terminaison d'extension Capgo ou API non authentifiés qui sont intentionnellement publics par conception — y compris les points de terminaison de mise à jour/stats qui ne nécessitent pas une clé API — ne sont pas des vulnérabilités. N'y signalez pas.
• La mise en cryptage incorrecte par l'uploader ou l'interface utilisateur pour les bundles servis via external_url n'est pas une vulnérabilité Capgo (la cryptage des bundles externes est hors du contrôle de Capgo ).

Supabase et Services tiers

Si la cause racine est un bug de la plateforme ou d'un service Supabase, signalez-l’à Supabase et non Capgo. Si la logique vulnérable, SQL, RPC, politique RLS, fonction Edge ou la configuration a été créée ou choisie par Capgo et que nous pouvons la corriger dans notre projet, elle est dans le champ même si Supabase sert l'endpoint. Pour les constats sur le comportement de Supabase lui-même, incluez un cas réplicable et la configuration Supabase exacte ou le changement de configuration qui l'empêche dans un projet configuré comme le nôtre.

Exemples

Limitations de Supabase Auth (Déjà signalées)

Certains résultats sont signalés à plusieurs reprises et sont causés par les paramètres Auth Supabase par défaut ou le comportement du plateau plutôt que Capgo code. Nous examinons ces derniers uniquement lorsque nous pouvons les reproduire dans un projet de démonstration Supabase partagé configuré comme le nôtre et lorsque la correction nécessite une modification de la configuration Supabase qui ne nécessite pas de modification des règles de sécurité Capgo. Si la correction nécessite de modifier les règles de sécurité SQL, les RPC, les politiques RLS, les fonctions ou la logique de l'application Capgo, signalez-le-nous car cela est dans le champ.

• Fournissez un cas de reproduction et identifiez la correction exacte : soit la modification de la configuration Supabase qui résout un problème de comportement Supabase, soit l'objet de configuration Capgo-propriétaire code qui doit changer.
• La vérification par courriel doit suivre les paramètres de votre projet Auth Supabase (par exemple, si la confirmation par courriel est désactivée et si l'authentification basée sur la capture est utilisée).
• Les flux d'actualisation de mot de passe et de récupération de compte ne nécessitent pas toujours la saisie ou la vérification du mot de passe ancien si Supabase Auth est configuré de cette manière.
• Si le problème est dans cette liste mais que vous pouvez montrer une correction Supabase concrète dans le projet fourni ou une défaut de sécurité Capgo-propriétaire, nous pouvons le considérer comme étant dans le champ.

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