なぜ危ないのか
Stripeの公開可能キー（pk-live_…）は決済フォームを動かすために必要ですが、秘密鍵（sk-live_…）やWebhookシークレット（whsec_…）がHTML内に直書きされていると、ソースを参照した第三者が即座に不正APIリクエストを送れる状態になります。社外レビューでは受け取った相手がブラウザの「ページのソースを表示」で確認できるため、添付メールの暗号化だけでは対策になりません。
特にAIツールで生成したHTMLは、プロンプトに環境変数の置き換えを明示しなかった場合にキーをそのまま埋め込んでしまうことがあります。生成結果を目視確認せずにzipで送付するケースでは発見が遅れ、Stripeダッシュボードのログに不正課金の痕跡が残って初めて気づく、という事態も報告されています。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
HTMLファイルをテキストエディタで開き、sk-live_ / sk-test_ / whsec_ / rk_live_ の4パターンを検索します。Stripe.jsを読み込むscriptタグ周辺や、fetchでAPIを呼ぶJavaScriptブロック内に含まれることが多いです。VSCodeであればCtrl+Fでファイル横断検索、macOSターミナルならgrep -r "sk-live_" ./で一括スキャンできます。
インラインScriptだけでなく、外部JSファイルとして読み込んでいる場合も要注意です。バンドルファイルを参照しているときはそのファイルも同様に検索してください。またdata-属性にキーを渡しているケースや、カスタムHTML要素の属性に埋め込んでいるケースも見落としがちなので、pk-live_やsk_で全文grep検索することを推奨します。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
キーが見つかった場合は、まずStripeダッシュボードでそのキーをローテーションし、旧キーを即時無効化してください。HTMLには環境変数プレースホルダ（例：__STRIPE_PK__）を残し、デプロイ時に置換するパイプラインを通す構成に変更します。社外への共有はキー除去後のファイルのみとし、テスト用途ならpk-test_に切り替えた版を使います。
ギガサイト便のようにパスワード認証や会員ドメイン制限を付与できるプレビューサービスを使うと、URLを知っている人全員が閲覧できる状態を避けられます。共有URLに有効期限を設定し、レビュー完了後は即座に無効化するフローを運用ルールとして明文化しておくと、次回以降の手戻りを防げます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
CI/CDパイプラインにgit-secretsやtruffleHogを組み込み、コミット時点でStripeキーのパターンを検出するルールを追加します。正規表現（sk|pk|rk|whsec）_（live|test）_[0-9a-zA-Z]{20,}をpre-commitフックに設定すれば、誤ってキーをコミットした瞬間にエラーで止められます。
AIツールでHTMLを生成するプロンプトには「APIキーや認証情報を一切含めず、プレースホルダ形式で出力すること」という制約を必ず追記します。また生成後のレビューをワークフローの必須ステップとして定義し、チェックリスト形式でPRテンプレートに組み込むと属人化を防げます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
pk-live_で始まるキーもHTML内に含めてはいけませんか？
公開可能キー（pk-live_）はクライアント側での使用を想定しており、HTML内に含めること自体はStripeの設計上許可されています。ただし不必要に露出させないよう、信頼できるドメインのみに制限するStripeダッシュボードの設定を合わせて行うことを推奨します。
テスト環境のsk-test_キーが漏れた場合も対応は必要ですか？
テストキーで実際の課金は発生しませんが、テストデータの参照や操作が可能になるためローテーションを推奨します。また本番キーと同じ管理体制のプロジェクトでは、テストキーの漏えいが本番キーの取り扱いの甘さを示すリスクシグナルになります。
Webhookシークレット（whsec_）はHTMLに書くケースがあるのですか？
通常はサーバー側でWebhookの署名検証に使うものなのでHTMLには不要です。AIが生成したコードでフロントエンドに誤って埋め込むパターンが報告されているため、このキーが見つかった場合は設計から見直してください。