---
title: "Stripeキーを含むHTMLを共有するときのリスクと対策"
description: "StripeキーがHTMLに含まれている状態でのリスクの大きさと、キーの種類に応じた対処法を理解したい開発者・担当者向け。本番・テスト・Publishable・Secretの違いをもとに、どこまで対応すべきかを判断できる。"
image: "https://giga-site.com/og-image.png"
canonical: "https://giga-site.com/articles/stripe-key-risk-countermeasure"
markdown: "https://giga-site.com/articles/stripe-key-risk-countermeasure/index.md"
category: "セキュリティ"
publishedAt: "2026-06-25"
updatedAt: "2026-06-25"
readingMinutes: 5
---
# Stripeキーを含むHTMLを共有するときのリスクと対策
StripeキーはPublishable KeyとSecret Keyで危険度が大きく異なり、どちらのキーがHTMLに含まれているかによって対策の優先度が変わる。Secret Keyが含まれている場合は最優先で無効化が必要であり、Publishable Keyであっても本番と開発の混在には注意が必要だ。リスクの実態と実行すべき対策を整理する。
> Source HTML: https://giga-site.com/articles/stripe-key-risk-countermeasure
> Article index: https://giga-site.com/articles/index.md
## なぜ危ないのか
Stripeキーの中で最も危険なのは `sk-live_`で始まる本番シークレットキーだ。このキーを持つ者はStripe APIを通じて支払いの作成・払い戻し・顧客情報の参照・サブスクリプションの変更など、アカウント上のほぼすべての操作を実行できる。HTMLのソースコードから取得するのに特別な技術は不要で、ブラウザの「ページのソースを表示」だけで十分だ。
次に危険なのは `sk-test_`（テスト環境のシークレットキー）だ。直接の金銭的被害は発生しないが、テスト環境の顧客データや決済履歴への不正アクセスが可能になる。攻撃者がテストキーを使ってAPIの挙動を調査し、本番環境への攻撃の手がかりにすることもある。`pk-live_`と`pk-test_`（公開可能キー）はフロントエンドへの埋め込みが認められているが、本番と開発が混在することで意図しない本番課金が発生するリスクがある。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
## ソースで見る場所
HTMLとJavaScriptファイルを対象に `sk-live_`・`sk-test_`・`pk-live_`・`pk-test_` の4パターンを検索する。VS Codeなら「フォルダを検索」機能でプロジェクト全体を一度にスキャンできる。`sk_`がヒットした場合はそれが最優先対処項目だ。`pk_`のみのヒットであればキーの種類と利用環境（本番/テスト）が一致しているかを確認する。
fetchやXHRのリクエストヘッダーにキーが埋め込まれているケースも確認する。`Authorization: Bearer sk_` のような形式でAPIコールが書かれているとgrepで `sk_` を検索すれば引っかかるが、文字列の連結やBtoa（Base64）でエンコードされているとパターンが変わる。確認のためブラウザのNetworkタブで実際にページを読み込み、Stripeへのリクエストのヘッダーを確認する動的チェックも併用する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
## 安全に共有する設定
`sk_`キーが検出された場合は共有を中止し、Stripeダッシュボードでそのキーをロールオーバーする。ロールオーバー後は旧キーが即時無効になるため、正規の使用箇所（バックエンドの環境変数等）を新キーに更新する。その後、プレースホルダに置換したHTMLを作成して共有を再開する。
`pk_`のみで`sk_`が含まれていない場合は、テスト用HTMLであれば`pk-test_`に統一して共有できる。本番用HTMLを共有する場合は`pk-live_`を含めたままでも技術的には問題ないが、認証付きのリンクで特定レビュアーのみに共有することを推奨する。Stripeダッシュボードの「開発者」→「APIログ」でキーの使用状況を確認し、想定外のAPIコールがないかを共有期間中に監視する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
## 再発防止ルール
Stripeを使う機能のAI生成プロンプトに「Stripe Secret Key（sk-live_・sk-test_）はコードに含めないこと。Publishable Key（pk_で始まるもの）のみクライアントサイドに使用し、値は`YOUR_STRIPE_PUBLISHABLE_KEY`プレースホルダで記述すること。決済インテントの作成はサーバーサイドAPIとして別途実装すること。」という制約を標準化する。
GitHub Secret Scanningを有効化し、`sk-live_`・`sk-test_`パターンを検出リストに追加する。これによりリポジトリへのプッシュ時に自動検出されてアラートが送信される。Stripeの制限付きキー機能を活用し、本番環境でも最小権限のキーを発行することで、万一漏えいしても被害範囲を限定できる。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
## よくある質問
### Stripeのシークレットキーが漏えいしたか不明な場合でも、ロールオーバーすべきですか？
漏えいの可能性が少しでもある場合はロールオーバーすることを推奨する。ロールオーバー自体は数分で完了し、新キーを正規の環境変数に設定し直せばサービス影響は最小限で済む。StripeのAPIログで不審なリクエストがないかも同時に確認する。
### Stripeの制限付きキーを使えばHTMLに含めても安全ですか？
制限付きキーでもシークレットキー（sk_）に分類されるものはHTMLに含めるべきではない。権限を絞ることで漏えい時の被害範囲は小さくなるが、APIへのアクセス手段を外部に渡す状況に変わりはないため、クライアントサイドにはPublishable Keyのみを使う設計を維持する。
### StripeのWebhookシークレット（whsec_で始まる文字列）もHTMLに含めてはいけませんか？
Webhookシークレットはサーバーサイドでペイロードの署名検証に使うものであり、HTMLには絶対に含めてはならない。漏えいするとWebhookペイロードを偽造されるリスクがある。`whsec_`を含む行がHTMLで見つかった場合は即座に削除し、Stripeダッシュボードでシークレットを再生成する。
## 関連記事
- [APIキー直書きを含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/hardcoded-api-key-risk-countermeasure/index.md)
- [Supabase anon keyを含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/supabase-anon-key-risk-countermeasure/index.md)
- [クリックジャッキングを含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/clickjacking-risk-risk-countermeasure/index.md)
- [http混在を含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/mixed-content-risk-risk-countermeasure/index.md)
- [XSSを含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/xss-risk-risk-countermeasure/index.md)
- [オープンリダイレクトを含むHTMLを共有するときのリスクと対策](https://giga-site.com/articles/open-redirect-risk-risk-countermeasure/index.md)
```json
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Stripeキーを含むHTMLを共有するときのリスクと対策",
"description": "StripeキーがHTMLに含まれている状態でのリスクの大きさと、キーの種類に応じた対処法を理解したい開発者・担当者向け。本番・テスト・Publishable・Secretの違いをもとに、どこまで対応すべきかを判断できる。",
"datePublished": "2026-06-25",
"dateModified": "2026-06-25",
"mainEntityOfPage": "https://giga-site.com/articles/stripe-key-risk-countermeasure",
"url": "https://giga-site.com/articles/stripe-key-risk-countermeasure",
"inLanguage": "ja",
"image": "https://giga-site.com/og-image.png",
"articleSection": "セキュリティ",
"author": {
"@type": "Organization",
"name": "ギガサイト便"
},
"publisher": {
"@type": "Organization",
"name": "ギガサイト便"
},
"mainEntity": [
{
"@type": "Question",
"name": "Stripeのシークレットキーが漏えいしたか不明な場合でも、ロールオーバーすべきですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "漏えいの可能性が少しでもある場合はロールオーバーすることを推奨する。ロールオーバー自体は数分で完了し、新キーを正規の環境変数に設定し直せばサービス影響は最小限で済む。StripeのAPIログで不審なリクエストがないかも同時に確認する。"
}
},
{
"@type": "Question",
"name": "Stripeの制限付きキーを使えばHTMLに含めても安全ですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "制限付きキーでもシークレットキー（sk_）に分類されるものはHTMLに含めるべきではない。権限を絞ることで漏えい時の被害範囲は小さくなるが、APIへのアクセス手段を外部に渡す状況に変わりはないため、クライアントサイドにはPublishable Keyのみを使う設計を維持する。"
}
},
{
"@type": "Question",
"name": "StripeのWebhookシークレット（whsec_で始まる文字列）もHTMLに含めてはいけませんか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "Webhookシークレットはサーバーサイドでペイロードの署名検証に使うものであり、HTMLには絶対に含めてはならない。漏えいするとWebhookペイロードを偽造されるリスクがある。`whsec_`を含む行がHTMLで見つかった場合は即座に削除し、Stripeダッシュボードでシークレットを再生成する。"
}
}
]
}
```