バイブコーディング製アプリの公開前セキュリティチェックリスト

なぜ確認する？

コードやログに残ったキーは、リポジトリの閲覧者やログの閲覧者へ広がります。漏えい後の請求・不正利用を止めるには、発見だけでなく失効と更新まで必要です。

確認すること

• リポジトリ、ビルドログ、エラーログに秘密の値がない
• 本番の秘密は集中管理され、最小権限で参照される
• 更新・失効の担当者と手順が決まっている

危険な状態

.env やソースへ値を直書きし、全員が同じ強いキーを使い、漏れたときにどこから止めるか分からない状態です。

見つけたら

公開を止め、キーを失効・再発行し、履歴とログから影響範囲を確認します。値そのものは共有せず、変数名と保管場所だけを記録します。

なぜ確認する？

開発中の操作が本番DBへ届くと、テストデータの投入や削除が事業データを壊します。接続情報だけでなく、DBユーザーの権限とネットワーク経路も対象です。

確認すること

• 開発・検証・本番でDB、接続情報、アカウントが分かれている
• アプリのDBユーザーが必要な操作だけを持つ
• 本番データを使わずに検証できる

危険な状態

ローカルの設定を切り替え忘れると本番へ接続し、管理者権限の接続文字列が複数の場所に複製されている状態です。

見つけたら

環境ごとの接続を分離し、不要なアカウントと権限を削除します。安全なテスト用データを用意して、切り替え確認を手順化します。

なぜ確認する？

ログインできることと、対象データを操作できることは別です。画面でボタンを隠すだけでは、直接リクエストされた操作を止められません。

確認すること

• 未ログイン、別利用者、低権限の3条件でサーバー側を試す
• 対象IDを変えても他利用者のデータを読めない・変更できない
• 認証失敗、セッション、パスワード再設定の扱いを確認する

危険な状態

フロントエンドだけで権限を判定し、APIが利用者と対象リソースの関係を検証していない状態です。

見つけたら

認証と認可の判定をサーバー側へ寄せ、利用者・対象・操作の組み合わせを拒否するテストを追加します。

なぜ確認する？

ログやエラー出力へ入力内容をそのまま記録すると、秘密や個人情報がログ閲覧者へ広がるおそれがあります。必要な事象を追跡しつつ、記録しないデータを先に決めます。

確認すること

• 入力値や秘密をログ・エラー・分析イベントへ出力していない
• ログへ必要な事象だけを記録し、値はマスキングしている
• ログの閲覧権限と、不要なログを削除する手順を確認している

危険な状態

デバッグログへフォーム全体を出力し、マスキングされていない状態です。

見つけたら

入力・エラー・監査ログの各地点で記録しない項目を定義し、マスキングとアクセス制御を追加します。既存ログに含まれる値の扱いも確認します。

なぜ確認する？

バックアップが「ある」だけでは、障害時に事業を戻せるとは限りません。復元できること、戻す順番、目標時間を事前に確認します。

確認すること

• バックアップの頻度、保管先、保持期間、閲覧権限が決まっている
• 実データを壊さない環境で復元テストを行っている
• 復旧目標と連絡・判断の担当が決まっている

危険な状態

バックアップの成否を見ておらず、復元手順が担当者の記憶だけにあり、復旧時間の目安を説明できない状態です。

見つけたら

復元テストを実施し、結果と所要時間を記録します。復旧手順を短いチェックリストにし、変更後も再テストします。

なぜ確認する？

問題が起きた後に事実を追えなければ、影響範囲も復旧の判断もできません。記録する内容と、誰がいつ気づくかをセットで設計します。

確認すること

• 認証・認可の失敗、重要操作、エラーを追跡できる
• ログに秘密や個人情報を含めず、時刻・対象・結果が分かる
• 異常を検知した通知先と、確認・対応の担当が決まっている

危険な状態

本番ログが無効で、エラーを画面に表示するだけ、または大量のログから重要な事象を見つけられない状態です。

見つけたら

重要操作のイベントを定義し、秘密を除いた構造化ログと通知条件を追加します。テストイベントで通知が届くことまで確認します。

なぜ確認する？

作った本人しか分からない構成は、障害対応と権限管理のボトルネックになります。公開前に、別の人が安全に運用できる情報を残します。

確認すること

• 構成、変数名、デプロイ、ロールバックの手順がある
• 復旧、監視、連絡先、責任範囲、既知の制約を記録している
• 秘密の値ではなく、保管場所と更新方法だけを示している

危険な状態

手順がチャットの断片に散らばり、停止・復旧・権限変更を誰も再現できない状態です。

見つけたら

READMEに「初回セットアップ」「通常運用」「障害時」「変更時」の4章を作り、作成者以外が手順を一度実行します。