跳过主要内容
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

查看仓库 报告安全问题

有效报告的要求

为了参加Bug Bounty计划，报告必须满足以下所有要求：

  • 您必须在我们的GitHub仓库中找出确切的文件和行号，哪里存在漏洞
  • 您的报告必须通过GitHub安全建议在相关仓库提交
  • 您必须提供漏洞的清晰描述及其潜在影响
  • 您必须提供可重现的步骤来演示问题

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

响应时间和尊严

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

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

重要： 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, fixed it, opened a pull request, and you have verified after release that the fix works for you. This process usually takes between 20 and 30 days. 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.

如何报告

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

不在范围内

  • Reports without exact code line references in GitHub
  • 没有通过 GitHub 安全性建议提交的报告
  • 理论性漏洞没有实际的概念证明
  • 第三方平台、依赖项或服务中的错误， 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可以修复的平台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 安全咨询联系我们