Programme de récompense pour les bugs

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

Code Open Source

Tout répertoire de l'organisation Capgo est sous licence libre. Vous pouvez examiner, auditer et contribuer à nos code.

GitHub Organisation : 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 ligne et le numéro de ligne dans notre GitHub répertoire où la vulnérabilité existe
• Votre rapport doit être soumis via GitHub Security Advisory sur le répertoire pertinent
• Vous devez inclure une description claire de la vulnérabilité et de son impact potentiel
• Vous devez fournir des étapes répéductibles pour démontrer le problème

Temps de Réponse et de 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 les 24 à 72 heures.
• Ne nous envoyez pas de spam. Plus de trois emails par jour est considéré comme du spam et sera bloqué.
• Nous ne payons pas les rapports qui ignorent ces règles ou sont du spam.
• Seuls les rapports en portée qui suivent ce programme de bug bounty sont acceptés ; tout autre peut être bloqué.
• Ne demandez pas de mises à jour de statut comme "avez-vous vérifié ?" ou des questions similaires. Une fois que nous confirmons avoir 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. Cliquez sur l'onglet "Sécurité"
3. Cliquez sur "Signalez une vulnérabilité" pour créer un nouveau conseil de sécurité
4. Incluez l'exacte chemin de fichier 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 de portée

• Les rapports sans références de ligne exactes code dans GitHub
• Les rapports ne soumis pas par le biais de GitHub Security Advisory
• Les vulnérabilités théoriques sans preuve de concept
• Les bugs dans les plateformes, les dépendances ou les services tiers que Capgo ne peut pas fixer directement (signalez-les en amont, par exemple vers Supabase)
• Les tentatives de manipulation ou de phishing
• Les attaques de service
• Les rapports de SSRF ou DNS spoofing contre les webhooks ou la prévisualisation du site. Ces fonctionnalités exécutent 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.
• Une application ou un projet de configuration propriétaire de l'utilisateur code ou qui ne sont pas détenus, expédiés ou contrôlés par Capgo, y compris des fichiers comme capacitor.config.ts, config.capacitor.ts, le code source de l'application code et les paramètres spécifiques à l'environnement.
• Accès aux fichiers du Capgo bundle 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.

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 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 lorsque Supabase sert l'endpoint. Pour les constats sur le comportement de Supabase lui-même, incluez un cas reproductible et le paramètre Supabase exact ou la modification de configuration qui l'empêche dans un projet configuré comme le nôtre.

Exemples

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

Certains résultats sont signalés à plusieurs reprises et sont causés par les paramètres par défaut de Supabase Auth ou le comportement de la plateforme plutôt que par Capgo code. Nous examinons ces cas 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 de 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, RPC, RLS, les politiques, les fonctions ou la logique de l'application Capgo, signalez-le-nous car cela est dans le champ.

• Fournir un cas réplicable et identifier 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/propriétaire code qui doit changer.
• Le comportement de la vérification par e-mail est attendu pour suivre les paramètres du projet d'authentification Supabase (par exemple, si la confirmation par e-mail 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 de l'ancien mot de passe si Supabase Auth est configuré de cette manière.
• Si l'incident est dans cette liste mais que vous pouvez montrer une correction concrète de Supabase côté ou un 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.