Programma di Ricompensa per Bug

Capgo is committed to security and transparency. All our code is open source, and we welcome security researchers to help us identify vulnerabilities in our codebase.

Open Source Code

Every repository in the Capgo organization is open source. You can review, audit, and contribute to our code.

GitHub Organization: github.com/Cap-go

Capgo Backend & Landing

Capgo backend and product repository (capgo.app API, dashboard, and related services)

Visualizza Repository Segnala Problema di Sicurezza

Capacitor Aggiornamento Plugin

Lo plugin di base Capacitor che gestisce gli aggiornamenti in tempo reale sui dispositivi mobili

Visualizza Repository Segnala Problema di Sicurezza

Requisiti per i Rapporti Validi

Per qualificarsi per il programma Bug Bounty, il tuo rapporto deve soddisfare TUTTI i requisiti seguenti:

Devi identificare l'esatto file e il numero di riga del nostro GitHub repository dove esiste la vulnerabilità
Il tuo rapporto deve essere inviato attraverso GitHub Advisory di Sicurezza sul repository pertinente
Devi includere una descrizione chiara della vulnerabilità e del suo impatto potenziale
Devi fornire passaggi riproducibili per dimostrare l'issue

Importante: Se non puoi fornire l'esatta riga di code in GitHub dove esiste il problema, il tuo rapporto non sarà eleggibile per il programma Bug Bounty. I rapporti devono essere inviati attraverso GitHub Advisory di Sicurezza solo. Le paghe sono gestite da Algora.io; per favore crea un account lì affinché possiamo pagarti direttamente sulla piattaforma.

Tempo di Risposta e Rispetto

Siamo amichevoli e paghiamo per i rapporti validi, ma non possiamo lavorare con persone che non rispettano il nostro tempo. Per favore, mantieni la comunicazione calma e segui questo programma.

Rispondiamo ai rapporti di sicurezza e alle violazioni entro 24-72 ore.
Non ci spammare. Più di tre email in un solo giorno è considerato spam e verrà bloccato.
Non paghiamo per i rapporti che ignorano queste regole o sono spam.
Sono accettati solo i rapporti in ambito di scopo che seguono questo programma di bug bounty; qualsiasi altra cosa può essere bloccata.
Non chiedere aggiornamenti sullo stato come "hai controllato?" o domande simili. Una volta che confermiamo di aver ricevuto il tuo rapporto, basta così. Dopo di che, ci sono ancora molte cose da fare e preparare una richiesta di pull può richiedere diversi giorni.

Importante: Capgo is a tiny bootstrapped company, so our bounty amounts are lower than large-company programs. Reports without a clear exploit path are paid up to $30 max. Exploits with real, reproducible impact on Capgo are paid up to $300 max. We accept and review security reports for Capgo plugins, but paid bounties for plugin code are limited to @capgo/capacitor-updater. Other Capgo plugins are free to use and are not part of our paid product offering, so reports for them are reviewed but unpaid. Payments are issued only after we have identified the issue, released the fix, and you have verified post-release that the fix works for you. Opening or linking a pull request alone does not qualify for payment. This process usually takes a few days to a few weeks depending on severity and release cadence. Please do not send messages like "to get paid"; payment happens only once the release is live and you've tested and validated the fix.

Come segnalare un bug

Naviga al repository relativo su GitHub
Clicca sulla scheda "Security"
Clicca su "Segnala una vulnerabilità" per creare un nuovo avviso di sicurezza
Includi il percorso file esatto e il numero di riga (le) dove la vulnerabilità esiste
Includi i passaggi dettagliati per riprodurre l'errore e spiega l'impatto di sicurezza

Fuori Scopo

Il rapporti senza riferimenti di riga esatti di code in GitHub
Il rapporti non inviati attraverso il GitHub Security Advisory
Il vulnerabilità teoriche senza prova di concetto
Bugs in terze parti, dipendenze o servizi che Capgo non può risolvere direttamente (segnalare quelli upstream, ad esempio a Supabase).
Prove di ingegneria sociale o tentativi di phishing
Attacchi di servizio di negazione
SSRF o spoofing DNS nei report contro webhook o anteprima del sito. Queste funzionalità eseguono infrastrutture serverless e non possono essere utilizzate per raggiungere l'infrastruttura privata Capgo, quindi non sono esploitabili nel nostro ambiente.
Configurazioni di progetto o applicazione code o di proprietà dell'utente che Capgo non possiede, distribuisce o controlla, compresi file come capacitor.config.ts, config.capacitor.ts, sorgenti dell'applicazione code e impostazioni specifiche dell'ambiente.
Accesso ai file del bundle Capgo o prove che i file del bundle possono essere scaricati. I file del bundle sono asset web pubblici, gli utenti sono informati di questo e l'accesso a loro non è considerato una violazione dei dati.
Unauthenticated Capgo plugin/API endpoints that are intentionally public by design — including channel_self set and update/stats endpoints that do not require an API key — are not vulnerabilities. Do not report them as such.
L'upload o l'interfaccia utente che etichettano erroneamente l'encryption per i bundle serviti via external_url non è una vulnerabilità Capgo (l'encryption dei bundle ospitati esternamente è fuori dal controllo di Capgo).

Supabase e Servizi di Terze Parti

Ecco il caso in cui la causa radice è un bug del piattaforma o servizio Supabase, segnalalo a Supabase, non Capgo. Se la logica vulnerabile, SQL, RPC, politica RLS, Funzione Edge o configurazione è stata creata o scelta da Capgo e possiamo risolverlo nel nostro progetto, è incluso anche quando Supabase serve l'endpoint. Per i ritrovamenti sulla comportamento Supabase stesso, includi un caso riproducibile e l'esatto impostazione Supabase o modifica di configurazione che lo prevenirebbe in un progetto configurato come il nostro.

Esempi

Non valido qui

Un bug della piattaforma, un'interruzione o un comportamento di Supabase che solo Supabase può risolvere
Un ritrovamento che non puoi riprodurre
Una pretesa che incolpa Capgo per il comportamento di Supabase senza mostrare un Capgo-controllato risoluzione o l'esatta impostazione Supabase/configurazione

Valido qui

Un Capgo-controllato errore di configurazione Supabase che possiamo risolvere nelle impostazioni del nostro progetto (con passaggi)
Un Capgo-posseduto SQL, RPC, RLS, funzione o problema di integrazione che causa un uso Supabase non sicuro
Un problema riproducibile nel progetto Supabase di Capgo, schema o politiche, anche se è esposto attraverso un endpoint Supabase

Limitazioni note di Autenticazione Supabase (Già segnalate)

Alcuni ritrovamenti vengono segnalati ripetutamente e sono causati da impostazioni di autenticazione Supabase o comportamenti del platform piuttosto che Capgo code. Rivediamo questi solo quando possono essere riprodotti in un progetto demo Supabase condiviso configurato come il nostro e quando la correzione è un cambiamento di configurazione Supabase che non richiede modifiche alle Capgo regole di sicurezza. Se la correzione richiede modifiche a SQL, RPC, politiche RLS, funzioni o logica dell'app di Capgo, segnalarlo a noi perché è in ambito.

Fornisci un caso riproducibile e identifica la correzione esatta: o il cambiamento di impostazione/configurazione Supabase che risolve un problema di comportamento Supabase, o l'oggetto Capgo-owned code/config che deve cambiare.
Il comportamento di verifica dell'e-mail è previsto che segua le impostazioni del progetto di autenticazione Supabase (ad esempio, se la conferma dell'e-mail è disabilitata e si utilizza l'autenticazione basata sulla cattura).
I flussi di aggiornamento della password e di recupero della conta possono non richiedere sempre la rientro della vecchia password o la riconferma se l'autenticazione Supabase è configurata in quel modo.
Se l'issue è in questa lista ma puoi mostrare una correzione concreta Supabase-side in progetto o un difetto di sicurezza concreto Capgo-owned, possiamo considerarlo in ambito.

Per domande sul nostro programma Bug Bounty, contattaci attraverso le nostre GitHub Security Advisories.