Programa de Bug Bounty

Capgo está comprometido con la seguridad y la transparencia. Todo nuestro code es open source y animamos a los investigadores de seguridad a ayudarnos a identificar vulnerabilidades en nuestro codebase.

Code Open Source

Cada repositorio de la organización Capgo es open source. Puedes revisar, auditar y contribuir a nuestro code.

Organización GitHub: github.com/Cap-go

Requisitos para reportes válidos

Para calificar para el programa de Bug Bounty, tu reporte debe cumplir con TODOS los siguientes requisitos:

• Debes identificar el archivo y la línea exacta en nuestro repositorio de GitHub donde reside la vulnerabilidad
• Tu reporte debe enviarse a través de la Security Advisory de GitHub en el repositorio correspondiente
• Debes incluir una descripción clara de la vulnerabilidad y su impacto potencial
• Debes proporcionar pasos reproducibles para demostrar el problema

Tiempo de respuesta y respeto

Somos amables y pagamos por reportes válidos, pero no podemos trabajar con personas que no respeten nuestro tiempo. Por favor, mantén una comunicación calmada y sigue este programa.

• Respondemos a reportes de seguridad y brechas en un plazo de 24 a 72 horas.
• No nos hagas spam. Más de tres correos en un solo día se considera spam y serás bloqueado.
• No pagamos por reportes que ignoren estas reglas o que sean spam.
• Solo se aceptan reportes dentro del alcance que sigan este programa de bug bounty; cualquier otro podría ser bloqueado.
• No pidas actualizaciones de estado como "¿lo has revisado?" o preguntas similares. Una vez que confirmemos la recepción de tu reporte, es suficiente. Después de eso, aún queda mucho trabajo por delante y preparar un pull request puede tardar varios días.

Cómo reportar

1. Ve al repositorio correspondiente en GitHub
2. Haz clic en la pestaña "Security"
3. Haz clic en "Report a vulnerability" para crear un nuevo security advisory
4. Incluye la ruta exacta del archivo y el número de línea(s) donde se encuentra la vulnerabilidad
5. Proporciona pasos detallados para reproducir el error y explica el impacto de seguridad

Fuera de alcance

• Reportes sin referencias exactas a líneas de code en GitHub
• Reportes no enviados mediante el Security Advisory de GitHub
• Vulnerabilidades teóricas sin prueba de concepto
• Bugs en plataformas de terceros, dependencias o servicios que Capgo no puede corregir directamente (repórtalos upstream, por ejemplo a Supabase).
• Intentos de ingeniería social o phishing
• Ataques de denegación de servicio
• Reportes de SSRF o DNS spoofing contra webhooks o la vista previa del sitio web. Estas funciones se ejecutan en infraestructura serverless y no pueden usarse para alcanzar la infraestructura privada de Capgo, por lo que no son explotables en nuestro entorno.
• Configuración de la aplicación o del proyecto de code que pertenece al usuario y que Capgo no posee, distribuye ni controla, incluidos archivos como capacitor.config.ts, config.capacitor.ts, el código fuente de la app code y ajustes específicos del entorno.
• Acceso a archivos de bundle de Capgo o pruebas de que los archivos de bundle pueden descargarse. Los archivos de bundle son assets web públicos, se informa a los usuarios de esto y el acceso a ellos no se considera una brecha de datos.
• Los endpoints de plugins de Capgo o de API sin autenticar que son públicos intencionalmente por diseño —incluidos channel_self set y los endpoints de update/stats que no requieren una API key— no son vulnerabilidades. No los reportes como tales.
• Que el uploader o la UI etiqueten incorrectamente el cifrado de los bundles servidos vía external_url no es una vulnerabilidad de Capgo (el cifrado de bundles alojados externamente está fuera del control de Capgo).

Supabase y servicios de terceros

Si la causa raíz es un bug de la plataforma o servicio de Supabase, repórtalo a Supabase, no a Capgo. Si la lógica vulnerable, SQL, RPC, política RLS, Edge Function o configuración fue creada o elegida por Capgo y podemos arreglarla en nuestro proyecto, está en scope aunque Supabase sirva el endpoint. Para hallazgos sobre el comportamiento de Supabase, incluye un caso reproducible y el ajuste o cambio de config exacto de Supabase que lo previene en un proyecto como el nuestro.

Ejemplos

Limitaciones conocidas de Supabase Auth (ya reportadas)

Algunos hallazgos se reportan repetidamente y los causan los valores por defecto de Supabase Auth o el comportamiento de la plataforma, no Capgo code. Solo los revisamos cuando se pueden reproducir en un proyecto de demo de Supabase configurado como el nuestro y cuando la solución es un cambio de configuración del lado de Supabase que no obliga a modificar las reglas de seguridad de Capgo. Si la solución requiere cambiar SQL, RPCs, políticas RLS, funciones o la lógica de la app que son propiedad de Capgo, repórtalo, porque eso sí está dentro del alcance.

• Proporciona un caso reproducible e identifica la solución exacta: ya sea el cambio de ajuste/configuración en Supabase que resuelve el problema de comportamiento, o el objeto code/config propiedad de Capgo que hay que modificar.
• El comportamiento de la verificación por email seguirá la configuración de tu proyecto de Supabase Auth (por ejemplo, si la confirmación de email está desactivada o si se usa auth basada en captura).
• Los flujos de actualización de contraseña y recuperación de cuenta pueden no requerir siempre volver a introducir la contraseña antigua o una nueva verificación si Supabase Auth está configurado así.
• Si el problema está en esta lista pero puedes demostrar una solución concreta del lado de Supabase en el proyecto proporcionado, o un defecto de seguridad concreto propiedad de Capgo, podemos considerarlo dentro del alcance.

Si tienes preguntas sobre nuestro programa de Bug Bounty, escríbenos a través de nuestros GitHub Security Advisories.