跳过主要内容
Capgo logo

Bug Bounty Program

Capgo 致力于安全和透明度。我们所有的code都是开源的，我们欢迎安全研究人员帮助我们识别代码库中的漏洞。

开源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

Main Capgo repository including backend services and landing website

查看仓库 报告安全问题

Capacitor Updater Plugin

The core Capacitor plugin that handles over-the-air updates on mobile devices

[View Repository] [Report Security Issue]

[Requirements for Valid Reports]

为了符合Bug Bounty计划的要求，提交的报告必须满足以下所有条件：

  • 您必须在我们的GitHub仓库中准确指出存在漏洞的文件和行号
  • 您的报告必须通过GitHub Security Advisory在相关仓库提交
  • 您必须提供漏洞的清晰描述及其潜在影响
  • 您必须提供可复现的步骤来演示问题

重要： 如果您无法提供code在GitHub中的确切行号，报告将不符合Bug Bounty计划的要求。报告必须通过GitHub Security Advisory提交。通过Algora.io处理付款；请在该平台上创建账户，我们可以直接在该平台上为您支付。

响应时间和尊严

我们友好且支付有效报告，但我们无法与不尊严我们时间的人合作。请保持沟通的平和，遵循此计划。

  • 我们在 24-72 小时内响应安全报告和安全事件。
  • 请勿滥发邮件。超过一天发送超过三封邮件将被阻止。
  • 我们不会为忽视这些规则或是垃圾邮件的报告支付报酬。
  • 我们只接受遵循此漏洞赏金计划的漏洞报告;其他任何报告都可能被阻止。
  • 请勿询问状态更新，如"您是否检查了?"或类似问题。我们确认收到您的报告后即可。之后，仍有大量工作需要完成，准备 pull 请求可能需要几天时间。

重要： Capgo 是一个小型的自举公司，所以我们的赏金金额较低。没有明确的利用路径的报告将最高支付 $30。具有真实、可复现影响的 Capgo 漏洞将最高支付 $300。我们接受并审查 Capgo 插件的安全报告，但对于 code 插件的付费赏金仅限于 @capgo/capacitor-updater。其他 Capgo 插件是免费使用的，不属于我们的付费产品，因此报告它们将被审查但不付费。我们只在确认问题、修复它、打开 pull 请求并您在发布后验证修复后才会发放报酬。这整个过程通常需要 20-30 天。请勿发送类似"要获得报酬"的消息；报酬只在发布后您测试并验证修复后才会发放。

如何报告

  1. 前往相关仓库的 GitHub
  2. 点击 "安全性" 标签
  3. 点击 "报告漏洞" 来创建一个新的安全性建议
  4. 包含具体的文件路径和行号（行号）来指出漏洞的位置
  5. 提供详细的步骤来复现问题并解释安全性影响

不在范围内

  • Reports without exact code line references in GitHub
  • 没有通过GitHub安全性建议提交的报告
  • 理论上的漏洞没有实际的证明
  • 第三方平台、依赖项或服务中的bug，Capgo无法直接修复（例如报告给 Supabase）。
  • 社会工程或钓鱼攻击
  • 拒绝服务攻击
  • SSRF 或 DNS 欺骗报告针对 webhook 或网站预览。这些功能在无服务器基础设施上运行，无法用来访问私有Capgo基础设施，所以它们在我们的环境中不可利用。
  • User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
  • 访问Capgo打包文件或证明打包文件可以下载。打包文件是公共网络资产，用户已知晓这一点，并且访问它们不被认为是数据泄露。

Supabase和第三方服务

如果根源是Supabase平台或服务的bug，请向Supabase报告，而不是Capgo。如果易受攻击的逻辑、SQL、RPC、RLS策略、边缘函数或配置由Capgo创建或选择，我们可以在项目中修复它，即使Supabase提供了端点。对于Supabase自身行为的发现，请包含可复现的案例和预防它的确切Supabase设置或配置更改，项目配置如我们的。

示例

在此无效

  • 仅Supabase可以修复的Supabase平台bug、停机或行为
  • 无法复现的发现
  • 声称Capgo对Supabase行为负责而没有显示Capgo控制的修复或确切的Supabase设置/配置更改

在此有效

  • Capgo控制的Supabase配置错误，我们可以在项目设置中修复（带有步骤）
  • Capgo拥有的SQL、RPC、RLS、函数或集成问题，导致不安全的Supabase使用
  • A Capgo 在 Supabase 项目、模式或策略中的可复现问题，即使它通过 Supabase 端点暴露也一样

已报告的 Supabase 认证限制

某些发现反复报告，并由 Supabase 认证默认值或平台行为引起，而不是 Capgo code。我们只会审查这些问题，当它们可以在我们的配置类似的 Supabase 演示项目中复现，并且修复需要 Supabase 端点配置更改，而不需要更改 Capgo 安全规则时。若修复需要更改 Capgo 所有者 SQL、RPCs、RLS 策略、函数或应用逻辑，请将其报告给我们，因为这在我们的范围内

  • 提供可复现的案例并确定具体的修复：要么是 Supabase 设置/配置更改来解决 Supabase 行为问题，要么是 Capgo 所有者 code/配置对象必须更改
  • 电子邮件验证行为应遵循您的 Supabase 认证项目设置（例如，是否禁用电子邮件确认并使用捕获式认证）
  • 密码更新和账户恢复流程可能并不总是需要旧密码重新输入或重新验证，如果 Supabase 认证配置为这样
  • 如果问题在此列表中，但您可以在提供的项目中展示一个具体的 Supabase 端点修复或一个具体的 Capgo 所有者安全缺陷，我们可以考虑它在我们的范围内

有关我们的 Bug Bounty 计划的任何问题，请通过我们的 GitHub 安全咨询联系我们