Claude Codeによるウェブアプリ向けセキュリティチェックリスト（短時間スポットチェック）

軽量なセキュリティ・スポットチェックとは

軽量なセキュリティ・スポットチェックは、出荷前に明らかで影響の大きい問題を素早く見つけるための短時間レビュー（通常30～60分）です。完全な監査ではありません。安全点検のように、実装で最も失敗しがちな箇所をざっと確認し、推測ではなく証拠を探します。

このClaude Codeセキュリティチェックリストは、日常のウェブアプリで最も壊れやすい領域に焦点を当てます：

• 認証の前提（ユーザーをどう特定するか）
• 認可の抜け（何が許可されるか）
• 入力の検証
• シークレットの扱い
• よくあるインジェクションの攻撃面（SQL、コマンド実行、テンプレートレンダリング、リダイレクト、アップロード）

バグの不存在を証明したり、高度な脅威モデルを扱ったり、ペネトレーションテストの代わりをするものではありません。

「具体的な所見」とは、記録する問題のすべてに開発者が直ちに対応できる証拠があることを意味します。各所見については次を記録してください：

• 正確なファイルと関数／ハンドラ名
• 危険な振る舞いを一文で
• 最小限の再現手順（リクエスト、ペイロード、クリック経路）
• なぜ問題か（影響）と誰がトリガーできるか
• 安全な修正の方向性（全面書き直しでない）

AIは補助ツールであり、最終判定者ではありません。検索、要約、テスト案の提案に使い、その後コードを読み、可能なら実際のリクエストで再現して検証してください。モデルが具体的な場所と手順を示せない場合は、その主張は未検証として扱ってください。

10分で範囲を決める

短時間レビューが機能するには対象を絞ることが必要です。Claude Codeに見てもらう前に、今日何を証明したいか、何をチェックしないかを決めてください。

まず、ミスが金銭被害、データ漏洩、権限付与につながる実際のユーザージャーニーを1～3個選びます。ログイン、パスワードリセット、チェックアウト、管理者編集画面などが良い候補です。

次に保護すべき資産を具体的に書き出します：ユーザーアカウント、決済操作、個人データ、管理者のみの操作など。

その後、守るべき脅威の前提を平易に書きます。好奇心でクリックするユーザーなのか、スクリプトを持つ外部攻撃者なのか、ある程度のアクセスを持つ内部者なのかで、「十分」と見なす基準が変わります。

最後に、合格／不合格の基準を定義して、スポットチェックが感覚ではなく所見で終わるようにします。シンプルなルールが有効です：

• 合格：すべての機密操作に明示的な認証（authn）と認可（authz）のチェックがある。
• 不合格：任意のエンドポイントがクライアントを信頼してユーザーIDやロールを受け取っている。
• 合格：入力はUIだけでなくサーバー側で検証されている。
• 不合格：シークレットがログ、設定、クライアントコードに含まれている。

失敗の具体像が説明できないなら、範囲がまだ曖昧です。

Claude Codeに渡すコンテキストを準備する

スポットチェックはモデルが正しい箇所を見ているときだけ有効です。レビューが推測ではなく証拠を出せるよう、小さなコードとメモの束を用意してください。

セキュリティ上重要なパス、つまりリクエストの入口と誰がユーザーかを決めるコードを共有し、データがどのように流れるかが分かるだけの周辺コードも含めます。

実用的なバンドル例：

• 認証入口：セッション／JWTの解析、クッキー設定、ログインコールバック、認証ミドルウェア
• ルートとハンドラ：コントローラ、RPCメソッド、GraphQLリゾルバ、バックグラウンドジョブハンドラ
• データ層：ORMクエリ、生SQLヘルパー、クエリビルダ、機密テーブルのマイグレーション
• ポリシーチェック：ロールチェック、所有権チェック、機能フラグ、管理者専用のエンドポイント
• 検証：リクエストスキーマバリデータ、ファイルアップロードハンドラ、デシリアライズコード

セッションかJWTか、トークンはクッキーかヘッダか、リバースプロキシやAPIゲートウェイの挙動、キュー／cronワーカー、内部専用のエンドポイントなど、前提を明確にするため数行の環境メモも追加してください。

バグを追う前に、エントリポイント、特権エンドポイント、触れるデータストアのインベントリを求めてください。これで見落としを防げます。

また、具体的な所見を出させる出力形式を合意しておくと良いです。シンプルな表：所見、重大度、影響を受けるエンドポイント／ファイル、証拠（正確なスニペットか行範囲）、悪用シナリオ、修正案、などが有効です。

30～60分レビューのステップバイステップ

時間配分：

• 10分：状況把握
• 15～30分：フロー追跡
• 10分：書き起こし

目的は完璧な網羅ではなく、テスト可能な少数の所見を出すことです。

アプリを開いた状態でコードを読み、UIを操作して発生するリクエストを観察します。ノートは具体的なエンドポイント、パラメータ、データソースを指すべきです。

一回の作業で完了するワークフロー例：

1. エントリポイントと信頼境界を図示する。公開ルート、ログイン済みルート、管理者ルート、Webhook、アップロード、サードパーティのコールバックをメモし、ユーザー制御データがサーバー信頼に変わる箇所をマークする。
2. 重要なエンドポイントごとに、IDを証明する箇所を記録する。チェックが「ミドルウェア」であるなら、すべてのルートが実際にそれを使っているか確認する。
3. 認可も同様に追う。別ユーザーのデータ閲覧、ロール変更、エクスポート、削除など、危険な操作を一つ選び、許可判断がデータベースクエリまでどう伝わるかを追跡する。
4. 入力がどこに到達するかを追跡する。リクエストのあるパラメータがSQL/ORMクエリ、テンプレートレンダリング、コマンド実行、URLフェッチ（SSRF）、リダイレクト、ファイルパスに至るまでを一つ追う。
5. トレース中にシークレットと設定の流れをスキャンする。トークンがログやクライアントコード、エラーメッセージ、環境ダンプに出ていないか確認する。

役立つ習慣："問題なさそう" と判断したら、それを壊す方法を必ず書く。壊し方を説明できなければ、十分に検証していない可能性が高いです。

認証（Authn）スポットチェック：誰であるかを立証する

認証は「このリクエストはこの人に属する」と決める箇所です。短時間のスポットチェックは全行を読むことではなく、本人性が確立される場所を見つけ、ショートカットや失敗パスを確認することにあります。

信頼境界を特定してください：どこで本人性が初めて作られたり受け入れられたりするか。セッションクッキー、JWTベアラートークン、APIキー、エッジでのmTLSなどがあります。Claude Codeに「anonymousをユーザーIDに変える正確なファイルと関数を示して」と依頼し、同等の別の経路がないかも列挙させてください。

注視すべき点：

• すべての認証入口（Webログイン、APIトークン、モバイル認証、内部サービス認証）を洗い出し、一貫したIDモデルに収束しているかを確認する。
• ログインやパスワードリセットにレート制限、ロックアウト、ユーザー列挙防止があるか（存在／非存在で異なるエラーメッセージや応答時間がないか）をチェックする。
• セッションとクッキー設定：HttpOnly、Secure、SameSite、有効期限、ログインや権限変更時のトークンローテーション、ログアウトの無効化（サーバー側での無効化が必要）を確認する。
• MFAとリカバリ：リカバリ経路がMFAより弱くなっていないか（例：メールのみのリセットでMFAを回避できないか）を確認する。
• 認証失敗ログ：運用に有用である一方、攻撃者に有利な詳細（"ユーザーが存在する" のヒントやトークンダンプ）を漏らしていないか注意する。

実用例：リセットメールが「アカウントが見つかりません」と返すのは列挙の問題ですが、応答時間差でも同じ事実が漏れることがあるので、タイミングもチェックしてください。

認可（Authz）スポットチェック：操作が許可されていることを証明する

認可の誤りは最も被害が大きくなりがちです。「このユーザーはこの操作をこのリソースで行って良いか？」が正しく判断されているかを壊す目的でテストします。

ロールと権限を平易な言葉で書き出してください。例：

• オーナーはメンバーを招待できる
• メンバーは自分のプロフィールを編集できる
• サポートは請求情報を閲覧できるがプランは変更できない
• 管理者はプロジェクトを削除できる

その上で、あらゆる機密操作がサーバー側で認可を強制しているか確認してください。UIでボタンを隠すだけでは不十分で、攻撃者はAPIを直接叩けます。

よく見つかる問題点：

• 作成、削除、エクスポート、ロール変更、請求アクセスに関わるエンドポイントを探す
• 各エンドポイントについて、サーバー側の権限チェック（フロントエンドではなく）を特定する
• user-controlledなID（projectId、userId、orgId）を見つけ、所有権チェックがあるか確認する
• 管理者専用パスがロール欠如時に閉じられる（fail closed）ことを確認する
• テナント境界：orgIdやaccountIdはセッションコンテキストから取得されており、リクエスト入力だけを信用していないか確認する

典型的なIDORの匂いは単純です：GET /projects/{id} のように {id} がユーザー管理下にあり、サーバーがそれが現在のユーザーに属するかを検証せずに読み込んでいる場合。

実地的なプロンプト例：

「このエンドポイントでアクセスを決定する正確なコードを示し、別のorgIdのユーザーがアクセスできてしまう具体的な条件を列挙してください。該当がなければ、ファイルと関数名でその理由を説明してください。」

入力検証：まずは不正なデータを入れさせない

多くのウェブアプリの問題は、アプリが想定していない入力を受け入れてしまうことから始まります。ここでいう「入力」は、ユーザーや他システムが影響を与えうるあらゆるものです。

まず、スポットチェック対象のエンドポイントの入力を列挙しましょう：

• URLのクエリやパス値
• リクエストボディフィールド（ネストしたJSONも含む）
• ヘッダ（認証ヘッダ、Content-Type、Forwarded IPなど）
• クッキー
• ファイルアップロード（名前、サイズ、タイプ、メタデータ）

検証はデータがアプリに入る境界近くで行うべきで、ビジネスロジックの奥深くではなく入口付近を見てください。基本を確認：型（文字列か数値か）、最大長、必須か任意か、形式（メール、UUID、日付）など。

ロールやステータス、ソート方向のように既知の値はホワイトリスト方式にするのが望ましいです。いくつかの悪い値をブロックするより安全です。

またエラー処理をチェックしてください。入力を拒否する際に、生の値をレスポンスやログ、UIにそのまま返すのは避けるべきです。小さな検証ミスがデータ漏洩や注入の助けになります。

危険なエンドポイント（ログイン、検索、アップロード、管理者操作）に対する簡単なテストプラン：

• 長すぎる文字列（10,000+文字）
• 型違い（配列を送るなど）
• 予期しない列挙値
• 意味を変える特殊文字
• 必須フィールドに空を送る

例：任意の文字列を受け取るソートパラメータは後でSQL断片になる可能性があります。"date"や"price"のような許可リストにするとこのクラスのミスを予防できます。

さっと確認する一般的なインジェクション面

短時間レビューで見つかる問題はだいたい同じ場所にあります：ユーザー入力がコード、クエリ、パス、URLとして解釈される箇所を探します。ここでは「入力が信頼境界を越える」瞬間を狩ります。

エントリポイント（クエリ、ヘッダ、クッキー、アップロード、管理フォーム）から、入力がどこに届くかをトレースしてください。

速攻で見るべき対象

以下のパターンを探し、各々について具体的な呼び出し箇所とペイロード例を求めてください：

• SQLインジェクション：文字列連結で組み立てるクエリ、動的なORDER BY、IN (...)を結合して作るビルダ
• XSS：HTMLレンダリング、テンプレート、Markdownプレビュー、リッチテキストエディタで「後でサニタイズする」前提
• コマンドインジェクション：画像処理、PDFツール、バックアップ、変換処理などでシェルコマンドにユーザー制御フラグを渡している箇所
• SSRF：Webhookやリンクプレビュー、URLからのインポート機能、内部ステータスチェックでユーザー提供のURLを受ける箇所
• パストラバーサル：ファイルダウンロード、ZIP展開、アップロードパイプラインで後で名前でファイルを読み出す箇所

デシリアライズやテンプレート注入にも気をつけてください。ユーザー提供のJSON、YAML、テンプレート化された文字列を解析する機能は、カスタム型や式をサポートしていると特に危険です。

機能がURL、ファイル名、整形テキストを受け入れるなら、コードパスとテストで証明できるまで悪用可能だと仮定してください。

シークレットの扱い：漏洩と弱い保管を見つける

シークレットの問題は探す場所が分かれば分かりやすいことが多いです。シークレットがどこに存在し、どこで誤ってコピーされうるかに注目しましょう。

シークレットが現れやすい場所：

• 環境変数やアプリ設定ファイル
• CIの出力やビルドログ（デプロイ失敗ログ含む）
• クライアントバンドルやモバイルビルド（ユーザーに配布されるもの）
• デバッグ用エンドポイント、ヘルスページ、管理ツール
• エラーページ、スタックトレース、解析イベント

次に、もしシークレットが露出していたら何が起きるかを具体的に問います。良い設計はローテーション手順（新しいキー発行）、取り消し（旧キー無効化）、再デプロイの迅速さがあることです。「後で変える」としか答えられないなら所見にしてください。

最小権限も重要な改善点です。キーに過剰な権限があるとインシデントの影響が大きくなります。データベースユーザーがテーブルをDROPできる、サードパーティトークンがアカウントを管理できる、環境を跨いでキーが共有される、などを探してください。サービスごと・環境ごとに鍵を分け、必要最小限の権限を与えましょう。

短時間のチェックで使えるプロンプト例：

• 「ハードコードされたトークン、パスワード、秘密鍵を検索してください。正確なファイルパスと一致した文字列パターンを列挙してください。」
• 「リクエストヘッダ、クッキー、env vars、完全なエラーオブジェクトをログに出力しているコードを探し、どの敏感フィールドが現れる可能性があるかログ行を示してください。」
• 「スナップショットやエクスポート、ビルドアーティファクトにシークレットが入るか確認してください。何がどこに保存されるかを特定してください。」

最後に、ガードレールを確認します：シークレットをソース管理から排除する（pre-commit/CIチェック）、バックアップやスナップショットに平文の資格情報が含まれないことを確認する。プラットフォームがスナップショットとロールバックをサポートするなら、シークレットは実行時に注入され、保存イメージに焼き込まれていないことを確かめてください。

具体的な所見を強制するプロンプト（コピペ用）

あいまいなプロンプトはあいまいな回答を呼びます。モデルに証拠を提示させるには、正確な場所、たどれるトレース、実行可能な再現手順、誤りを示す条件を求めます。

一度に一つのパターンを使い、修正が必要なら出力を更新させてください。

• ファイルレベルの証拠：「リポジトリを検索してauth、sessions、tokens、middlewareを名前で挙げ、正確なファイル、関数、行範囲を示してください。関連スニペットを引用してください。コードを指せない場合は 'no evidence found' と答えてください。」
• 入力からシンクまでのトレース：「一つのユーザー制御入力（ヘッダ、クエリ、ボディ、クッキー）を選び、エントリポイントから使用される場所（SQL、HTML、シェル、テンプレート、リダイレクト、ファイルパス）までのデータフローを関数ごとに示してください。」
• 再現手順：「curlの最小再現（メソッド、URLの形、ヘッダ、ボディ）を出してください。期待されるステータスコードと成功／失敗例を含め、前提（ロール、認証状態）を明記してください。」
• 誤検知コントロール：「この所見を否定するには何を確認すればよいか。設定フラグ、ミドルウェアの順序、ホワイトリスト検証、パラメータ化クエリ、フレームワークのエスケープなど2～3個挙げてください。存在する場合はリスクがどう変わるか説明してください。」
• 最小限の安全な修正＋テスト：「問題をブロックしつつ正当ケースを壊さない最小の変更を提案し、追加すべきテスト（名前、意図、入力、期待結果）を一つ書いてください。トレードオフがあれば明記してください。」

出力がまだあいまいなら、次でピンポイントに指示します：

"file path, function name, risky line, and one-sentence impact のみで答えてください。"

現実的な例：仮説を検証済みの問題に変える

プロフィール更新エンドポイントは所有権ミスを隠しがちです。ここでチェックリストを通して検討できる小さなケースを示します。

シナリオ：APIがユーザープロフィールを更新する場合：

PATCH /api/profile?accountId=123 に { "displayName": "Sam" } のようなJSONを送るとします。

Claude Codeにハンドラを見つけさせ、accountId の使われ方を追跡し、サーバーが所有権を強制しているか証明してもらいます。

よく見つかる結果：

• 認証（Authn）： リクエストはセッションかトークンを必要とするので保護されているように見える。
• 認可（Authz）： ハンドラがクエリ文字列からaccountIdを信頼しており、ログイン済みユーザーと照合せずに同アカウントを更新してしまう。
• 入力検証： displayNameはトリムされるが、accountIdは整数として検証されていない。
• 注入面： SQLが文字列連結で組み立てられている例："... WHERE account_id=" + accountId。

良い報告は具体的です：

• 重大度： 高（IDOR＋場合によってはSQLインジェクション）
• 証拠： 有効なログインで別のアカウントをaccountIdを書き換えて変更できる。SQLが未検証の入力で組み立てられている。
• 修正： クライアントのaccountIdを無視し、サーバー側で認証されたユーザーのアカウントIDを使う。クエリはパラメータ化する。
• テスト： 別のアカウントを更新しようとして403を期待する。非数値のaccountIdを拒否する。

修正後の素早い再チェック：

• 別のaccountIdで同じリクエストを送り失敗することを確認する。
• サーバーログがクエリパラメータではなく認証済みIDを使っていることを確認する。
• クエリがプレースホルダ／パラメータを使い、文字列連結でないことを確認する。
• 文字列や非常に大きな数などに対するネガティブテストを1つ実行する。

スポットチェックで見落としやすい罠

UIが強制しているように見えることを信用するのは最速で脆弱性を見逃す方法です。ボタンを隠しているだけでは権限チェックではありません。サーバーがリクエストを受け入れているなら、誰でもリプレイできます。

もう一つの落とし穴はあいまいな依頼です。「セキュリティレビューをして」に対しては総論的なレポートが返るだけです。スポットチェックは範囲（どのエンドポイント、どのロール、どのデータ）が狭く、出力形式（ファイル名、関数、危険行、最小再現）を厳格にする必要があります。

AI出力にも同じルールを適用してください：所見に具体的なコード位置と手順がないなら未検証として扱います。

スポットチェックが外れる典型的な例

よくある失敗：

• 管理ページだから「管理者専用」と仮定してしまうが、サーバー側で検証されていない
• 「Xをバイパスできるリクエストを見せて」と具体的に頼まず広範なレビューを求める
• 「可能性のあるSQLインジェクション」と言われても、クエリ構築箇所と入力経路が示されない
• Webhookやスケジュールジョブ、インポートツール、内部管理アクションなど見落としやすい入口をスキップする
• 事象をパッチ的にフィルタや正規表現で塞ぐが、根本原因である検証不足や認可不足を残す

もしフィルタを増やしてばかりいるなら一旦止まりましょう。修正は多くの場合、境界での検証と認可チェックを早い段階で明示的かつ集中させることです。

出荷前にできる短時間チェック

これらは完全なレビューの代わりにはなりませんが、疲れているときに紛れ込むミスを見つけます。すぐに証明できるものに集中してください：送れるリクエスト、開けるページ、見つけられるログ行など。

通常効果がある5つの短いスポットチェック：

• 認証の摩擦： 10回の間違ったログインを試してみる。レート制限やロックアウト、少なくとも遅延があるか。エラーメッセージやタイミングでメールの存在が分からないか。
• ID入れ替えでの認可テスト： 実在するリソース（注文、請求書、プロフィール）を選び、URLやJSONボディ、GraphQL変数のIDを書き換える。自分のものでないデータが見えないか確認する（メタデータ含む）。
• 入力ガードレール： 主要フィールド（メール、名前、検索、ファイル）に長すぎる文字列、奇妙なUnicode、型違いを送る。長さ制限やホワイトリストが効いているか。
• シークレット露出： 最近のログやクライアントバンドルでトークン、APIキー、JWT、"Authorization: Bearer"が含まれていないか検索する。エラーページもチェックする。"ステージングだけ" が出荷されることはよくある。
• 注入面： SQLやテンプレート、シェルコマンド、リダイレクトURLへの文字列連結を探す。入力がこれらに届くなら、強い検証があるまではリスクがあると仮定する。

今週中に出せるトップ3の修正を書き出してください。願望リストではなく実際に出せるもの：例（1）ログインとパスワードリセットにレート制限を追加、（2）"idで取得"エンドポイントにサーバー側の所有権チェックを強制、（3）検索フィールドの入力長を上限し予期外文字を拒否。

次のステップ：このチェックリストをビルドプロセスに組み込む

スポットチェックは所見が出ても、それが出荷に反映されなければ意味がありません。チェックリストを小さく繰り返し実行可能なビルドステップにしてください。

各所見を分かりやすいバックログ項目に変換します：

• 修正内容：コードか設定で何を変えるか
• テスト：どのリクエスト、どのユニットテスト、どのQA手順で直ったことを証明するか
• 責任者：一人の担当者を決める
• 目標日：次のリリースか特定の日付
• 証拠：問題を示したファイル／エンドポイントと正確なリクエストやペイロード

リスクとチーム規模に合わせた頻度を選んでください。多くのチームはリリースごとが理想です。頻繁にリリースする場合は月次で30～60分のレビュー、出荷前に短いチェックを入れると良いでしょう。

繰り返しやすくするために、再利用可能なプロンプトパックとチェックリストテンプレートを作ってください。プロンプトはルート、ガード、失敗リクエスト、期待挙動を示す具体的な出力に絞ります。チームが普段使う場所にパックを保管しておくとスキップされにくくなります。

チャットでアプリを作るなら、設計段階でチェックリストを組み込みます。認証・認可・入力・シークレットに関する短い「セキュリティ前提」メモを付け、最初のワーキングバージョンの直後にスポットチェックを実行してください。

Platforms like Koder.ai (koder.ai) は、迅速に繰り返し作業しつつレビューのチェックポイントを維持するのに適しています。スナップショットとロールバックをリスクのある変更に対して使えると、セキュリティ修正を出荷しやすくなります。