Aller directement au contenu principal
Capgo logo

Programme de récompense pour les failles de sécurité

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

Logiciels open source Code

Tous les dépôtoirs de l'organisation Capgo sont sous licence open source. Vous pouvez examiner, auditer et contribuer à nos code.

Organisation GitHub : github.com/Cap-go

Capgo Backend & Landing

Dépôt principal de Capgo comprenant les services backend et le site web de lancement

Afficher le dépôt Signaler une faille de sécurité

Capacitor Updater Plugin

Le plugin de base Capacitor qui gère les mises à jour en ligne sur les appareils mobiles

Voir le Répertoire Signaler un Problème de Sécurité

Exigences pour les Rapports Valides

Pour être éligible au programme de 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 GitHub répertoire où la vulnérabilité existe
  • Votre rapport doit être soumis via GitHub Advisory de Sécurité 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éproubables pour démontrer le problème

Important : Si vous ne pouvez pas fournir l'exacte ligne de code dans GitHub où le problème existe, votre rapport ne sera pas éligible pour le programme de Bug Bounty. Les rapports doivent être soumis via GitHub Advisory de Sécurité uniquement. Les paiements sont gérés via Algora.io ; veuillez créer un compte là-bas afin que nous puissions vous payer directement sur la plateforme.

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.

  • We répondons aux rapports de sécurité et aux breaches dans les 24-72 heures.
  • Ne nous envoyez pas du 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 pertinents qui suivent ce programme de bug bounty sont acceptés; tout autre peut être bloqué.
  • Ne demandez pas d'informations sur l'état de votre rapport, comme "avez-vous vérifié ?" ou des questions similaires. Une fois que nous avons confirmé 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.

Important : Capgo est une petite entreprise auto-suffisante, donc nos montants de la prime sont inférieurs à ceux des grands programmes d'entreprise. Les rapports sans un chemin d'exploitation clair sont payés jusqu'à 30 $ au maximum. Les exploits avec un impact réel et réprouvable sur Capgo sont payés jusqu'à 300 $ au maximum. Les paiements sont émis uniquement après que nous ayons identifié le problème, le corrigé, ouvert une demande de tirage, et que vous avez vérifié après la mise en production que la correction fonctionne pour vous. Ce processus prend généralement entre 20 et 30 jours. Veuillez ne pas envoyer de messages comme "pour obtenir des paiements"; les paiements ne se produisent qu'une fois la mise en production est terminée et que vous avez testé et validé la correction.

Comment signaler un problème

  1. Naviguez vers le répertoire pertinent sur GitHub
  2. Cliquez sur l'onglet "Sécurité"
  3. Cliquez sur "Signaler une vulnérabilité" pour créer un nouveau avis de sécurité
  4. Incluez l'emplacement de fichier et le numéro de ligne exacts où la vulnérabilité existe
  5. Fournit des étapes détaillées pour reproduire le problème et expliquez l'impact de sécurité

Hors champ

  • Les rapports sans références de ligne exactes code dans GitHub
  • Les rapports ne soumis pas par le biais de GitHub de la sécurité de l'avertissement
  • Les vulnérabilités théoriques sans preuve de concept
  • Les bogues 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 phishing ou de manipulation sociale
  • Les attaques de service en rejet
  • Les rapports de SSRF ou de spoofing DNS contre les webhooks ou les prévisualisations du site Web. Ces fonctionnalités exécutent des infrastructures sans serveur et ne peuvent pas être utilisées pour atteindre l'infrastructure privée Capgo , donc elles ne sont pas exploitable dans notre environnement.

Supabase et Services tiers

Si la cause racine est un bug de la plateforme ou d'un service Supabase, signalez-le à 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 lorsque Supabase sert le point de terminaison. Pour les constats sur le comportement de Supabase lui-même, incluez un cas réplicable et la configuration Supabase ou la modification de configuration exacte qui l'empêche dans un projet configuré comme le nôtre.

Exemples

Not valide ici

  • Un bug, une panne ou un comportement de la plateforme Supabase que seul Supabase peut corriger
  • Un problème que vous ne pouvez pas reproduire
  • A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change

Not valide ici

  • A Capgo-controlled Supabase misconfiguration we can fix in our project settings (with steps)
  • Un problème de sécurité causé par une utilisation non sécurisée de Supabase, lié à un problème SQL, RPC, RLS, fonction ou intégration propriétaire de Capgo
  • Un problème reproducible dans le projet Supabase de Capgo, même si il est exposé à travers un point d'entrée Supabase

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

Certains problèmes 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 revoyons ces problèmes 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 un changement de configuration de Supabase qui ne nécessite pas de modification des règles de sécurité Capgo. Si la correction nécessite un changement de SQL, RPCs, politiques RLS, fonctions ou logique d'application propriétaire de Capgo, signalez-le-nous car cela est dans notre champ d'action.

  • Fournissez un cas reproducible et identifiez la correction exacte : soit le changement de configuration de Supabase qui résout un problème de comportement Supabase, soit l'objet Capgo-propriétaire code/config qui doit changer.
  • Le comportement de vérification par e-mail est attendu pour suivre les paramètres de projet Auth Supabase (par exemple, si la confirmation par e-mail est désactivée et l'authentification basée sur la capture est utilisée).
  • Mises à jour de mot de passe et flux 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 le problème est dans cette liste mais que vous pouvez montrer une solution concrète de Supabase pour ce projet ou un défaut de sécurité Capgo-propriétaire, nous pouvons le considérer dans le champ.

Pour des questions sur notre programme de Bug Bounty, veuillez nous contacter à travers nos GitHub Avis de Sécurité.