Skip to main content

セキュリティポリシー

連絡先: https://github.com/Cap-go/capgo/security/advisories/new
Canonical: https://capgo.app/security.txt

At Capgo, we consider the security of our systems a top priority. However, no matter how much effort we put into system security, there can still be vulnerabilities present.

脆弱性を発見した場合、できるだけ早く対処できるように、ご協力いただけますか。私たちのクライアントやシステムをよりよく保護するために、ご協力いただけますか。

範囲外の脆弱性:

  • ページに機密情報の操作ができない場合のクリックジャッキング
  • 未認証のログアウト/ログインのCSRF
  • ユーザーのデバイスへの物理的アクセスやMITM攻撃が必要な攻撃
  • 社会的エンジニアリングが必要な攻撃
  • サービス障害 (DoS) による活動
  • コンテンツの偽装やテキストの挿入に関する問題
  • メールの偽装
  • DNSSEC、CAA、CSP ヘッダーの欠如
  • 非機密性の Cookie に対して Secure または HTTP only フラグの欠如
  • 死リンク
  • ユーザー情報の漏洩
  • SSRF or DNS spoofing reports against webhooks or website preview. These features run on serverless infrastructure and cannot be used to reach private Capgo infrastructure, so they are not exploitable in our environment.
  • 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.
  • Access to Capgo bundle files or proof that bundle files can be downloaded. Bundle files are public web assets, users are informed of this, and access to them is not considered a data breach.

バンドルファイルへのアクセス

Some findings are repeatedly reported and tied to Supabase Auth behavior. These are only treated as Supabase-side issues when they can be reproduced in a shared Supabase demo project configured like ours and when a Supabase configuration change fixes the behavior without changing Capgo security rules. If the fix requires changing Capgo-owned SQL, RPCs, RLS policies, functions, or app logic, that is a Capgo issue and should be reported to us.

  • Reports must include a reproducible demo Supabase project, with steps, that matches our settings and demonstrates the behavior.
  • Reports must include the exact fix path: either the Supabase setting/config change that resolves the behavior, or the Capgo-owned code/config object that must change.
  • Account/email flows are validated against the Supabase project settings (for example, whether email verification is disabled and capture flow is used).
  • Password and email/password update flows may depend on current Supabase Auth session and re-verification settings.
  • If a demo project proves a concrete Supabase-side fix with no Capgo policy change, or shows a concrete Capgo-owned defect, we review it as actionable.

Testing guidelines:

  • Do not run automated scanners on other customer projects. Running automated scanners can run up costs for our users. Aggressively configured scanners might inadvertently disrupt services, exploit vulnerabilities, lead to system instability or breaches and violate Terms of Service from our upstream providers. Our own security systems won't be able to distinguish hostile reconnaissance from whitehat research. If you wish to run an automated scanner, notify us at security@capgo.app and only run it on your own Capgo project. Do NOT attack projects of other customers.
  • 脆弱性や問題を発見した場合、その利用は行わないでください。たとえば、脆弱性を示すために必要なデータより多くのデータをダウンロードしたり、他の人のデータを削除したり、変更したりしないでください。

報告ガイドライン:

  • Submit your findings through our GitHub Security Advisory:: https://github.com/Cap-go/capgo/security/advisories/new
  • 問題を再現するための十分な情報を提供してください。そうすることで、問題をできるだけ早く解決できるようになります。
  • Capgo プラグインのセキュリティレポートを受け付けて、レビューしますが、@capgo/capacitor-updater によって支払われる code プラグインの有料ボーナスは制限されています。Capgo プラグインは、有料製品の範囲外です。したがって、有料製品の提供を含まない Capgo プラグインのレポートは、支払われません。

漏洩ガイドライン:

  • 漏洩を防ぐために、問題を他の人に明らかにしないでください。問題を調査し、対処し、影響を受ける顧客に知らせるまで、待ってください。
  • Capgo についての研究を公開したい場合は、発表予定日から 30 日以上前に、レビューと承認のために、ドラフトを提出してください。次の情報は含めないでください:
    • Capgo の顧客プロジェクトに関するデータ
    • Capgo の顧客のデータ
    • Capgo の従業員、契約社員、パートナーに関する情報

保証するもの

  • 報告を受けた場合、7営業日以内に報告の評価と解決の予定日を含む回答を提供します。
  • 報告の指示を遵守している場合、報告に関してはあなたに対して法的措置をとることはありません。
  • あなたの報告は厳格な機密性で取り扱われ、第三者にあなたの個人情報を提供することはあなたの許可なしにありません。
  • 問題の解決に向けての進捗状況についてはあなたに情報を提供します。
  • 問題の報告に関する公の情報において、問題の発見者としてあなたの名前を明らかにします (あなたがそう望まない場合を除きます)。
  • 共有されたログに漏れたデータが存在する場合、問題の修正に使用されるデバッグ情報として扱います。報復や復讐の理由にはなりません。

問題を解決するにはできるだけ早く取り組み、問題が解決された後、最終的な問題の公開に積極的に参加したいと考えています。