AIで作ったアプリのセキュリティチェックリスト：公開前に確認すべきこと

実際のユーザーがAIで作ったアプリを使う前に、7つの点を確認してください。すべてのページとAPIが、利用者が誰で何をしてよいかを確認していること。シークレットキーはサーバー側にあり、ブラウザやチャットには置かないこと。すべての入力をサーバー側で検証すること。各ユーザーが自分のレコードにしかアクセスできないこと。ログインと費用のかかるエンドポイントにレート制限があること。依存パッケージが最新であること。そして、何か問題が起きてもデータを復元できること。以下のチェックリストでは、それぞれをコードを読まずに実行できる具体的なテストに落とし込んでいます。

AIアプリビルダーは機能を動かすのが得意です。しかし、自動的に慎重になるわけではありません。「慎重に」という指示は、プロンプトに書かれることがほとんどないからです。以下の問題の多くは、誰も求めなかったことから生まれます。そのため、解決策は多くの場合、AIに頼むことです。

このチェックリストの使い方

順番に進め、各項目について2つのことをしてください。AIに依頼して対応されているか確かめ、そして自分でテストすることです。権限チェックを書くのはAIにできますが、それが正しく動くかどうかはテストでしか分かりません。項目には次の印が付いています。

• 必須 — ほかの人がアプリを使う前に行う。
• 推奨 — 実際のユーザーや実データを扱う前に行う。
• 後で — アプリの成長に合わせて行う価値がある。

時間が1時間しかない場合は、すべての必須項目を行ってください。

1. 認証：この人は誰か？

認証とは、相手が誰かを確認することです。通常はログインを指します。基本については認証とはを、ログインの選択肢についてはアプリにログインを追加する方法をご覧ください。

• 必須： 非公開データを表示するすべてのページでログインを要求すること。テスト方法：ログアウトしてから、非公開ページのURLをブラウザに直接貼り付けます。
• 必須： それらのページの背後にあるすべてのAPIエンドポイントでも、ページだけでなくログインを要求すること。テスト方法：ログアウトした状態でブラウザのネットワークタブを開き、ログイン中にアプリが送ったリクエストを再実行します。
• 必須： パスワードは、平文ではなく、低速なパスワードハッシュアルゴリズムでハッシュ化して保存すること。OWASPのパスワード保存ガイダンスでは、まずArgon2idを推奨し、代替としてscrypt、bcrypt、PBKDF2を挙げています。AIに「パスワードはどのように保存されていますか？」と確認してください。
• 推奨： パスワードリセットのリンクは期限が切れ、1回だけ使えること。
• 推奨： セッションCookieにSecure、HttpOnly、SameSiteが設定されていること。また、ログアウトするとサーバー側でもセッションが終了すること。
• 後で： 二要素認証を提供すること、またはそれに対応したプロバイダーでのサインインを使うこと。

ユーザーデータを返すすべてのAPIルートとページを確認してください。それぞれが、ログインしていないユーザーからのリクエストを、ページのコードだけでなくサーバー側で拒否する必要があります。確認したルートを一覧にしてください。

2. 認可：何をしてよいか？

認可は、ログインの次の段階です。この特定のユーザーが何を見て、何を変更してよいかを決めます。AIで作ったアプリに重大な穴が開くのは、ここが最も多いポイントです。アプリは正しく見えます。各ユーザーのダッシュボードには自分のデータしか表示されていません。しかし、サーバーに直接頼まれれば、誰のデータでも渡してしまうのです。

• 必須： すべての読み取り、更新、削除で、そのレコードが現在のユーザー（またはそのチーム）に属しているかを、サーバー側で確認すること。
• 必須： テスト方法：アカウントAとBを作成します。Aとしてログインし、Aのレコードを1つ開き、URLまたはネットワークリクエストのIDをメモします。次にBとしてログインし、同じIDをリクエストします。Bはエラーを受け取る必要があり、Aのデータが表示されてはいけません。
• 必須： 管理画面と管理用APIエンドポイントは、ユーザーのロールをサーバー側で確認すること。管理画面へのリンクを隠しただけでは保護になりません。
• 必須： ユーザーがリクエストを書き換えて、自分のロール、価格、残高、所有者フィールドを変更できないこと。テスト方法：ネットワークタブで、プロフィールを更新したときに送信される内容を確認します。roleやisAdminのようなフィールドが含まれていれば、クライアントからそれらを無視するようAIに依頼してください。
• 推奨： URLのIDは推測しにくいこと（1、2、3ではなくランダムなID）。これは権限チェックの代わりにはなりませんが、チェックが抜けていた場合の被害を抑えられます。

レコードを読み取ったり変更したりするすべてのエンドポイントについて、ログインしているユーザーがそのレコードを所有しているか、またはアクセスを許可されているかを、サーバー側で確認してください。許可されていなければ404を返します。そのうえで、2つのアカウントを使ってこれをどうテストするか示してください。

3. データベースの行レベルのアクセス制御

「行レベルのアクセス制御」とは、テーブルの各行（1件の予約、1件の請求書など）が、その行に属するユーザーにしか見えないようにすることです。これを実現する方法は主に2つあります。

どちらの方法でも適切に行えます。重要なのは次の点です。

• 必須： ブラウザがデータベースに直接接続する場合（ホスト型のデータベース製品の中には、この方式を許可しているものがあります）、すべてのテーブルで行レベルのルールを有効にすること。ルールがなければ、公開キーを持つ人はテーブル全体を読めてしまいます。
• 必須： クエリは、ブラウザから送られたIDではなく、現在のユーザーまたはチームで絞り込むこと。
• 推奨： 共有データ（チームのプロジェクトなど）には、誰がチームに含まれるかの明確なルールを設け、1か所で強制すること。

4. シークレットとAPIキー

APIキーは、サービスのパスワードのようなものです。Stripe、メール、AIプロバイダーはすべてAPIキーを使います。背景については環境変数とシークレットとはをご覧ください。

• 必須： キーはプロジェクトの環境変数またはシークレットに保存し、コードに直接書き込まないこと。
• 必須： お金を使えてしまうキーや非公開データを読めてしまうキーは、サーバー側でのみ使うこと。テスト方法：公開中のサイトを開き、ページのソースと、開発者ツールでJavaScriptファイルを確認し、キーの先頭（例：sk_）を検索します。見つからなければOKです。
• 必須： キーをチャット、公開リポジトリ、スクリーンショットに貼り付けたことがないこと。もし貼り付けていたら、プロバイダーでキーを再発行してください（新しいキーを作成し、古いキーを削除します）。
• 推奨： プロバイダーが提供している場合は、制限付きのキー、またはスコープを絞ったキーを使うこと。たとえばStripeは、連携に必要な権限だけを持つ制限付きキーを推奨しています。
• 推奨： テスト用キーと本番用キーは分けること。本番アプリは、準備ができてから本番用キーを使うこと。

一部のキーは公開されることを前提に設計されています。たとえば、Stripeの公開可能キー（pk_…）や、自社ドメインに限定した地図のキーです。このルールは、権限を与えるキーに関するものであり、キーのように見える文字列すべてを対象とするものではありません。

5. 入力の検証

ユーザーが送るものすべて（フォームの項目、ファイルのアップロード、URLパラメータ）は、フォームで許可されている内容だけとは限らず、どんな値でもあり得ます。

• 必須： 検証はブラウザだけでなく、サーバー側で行うこと。ブラウザでのチェックは利便性のためのもので、誰でも回避できます。
• 必須： データベースのクエリは、ユーザーの入力を文字列として連結するのではなく、パラメータを使うこと（これでSQLインジェクションを防げます）。AIに確認してください。
• 必須： ユーザーが入力したテキストは、HTMLとして実行されず、テキストとして表示されること。テスト方法：名前の欄に<b>hello</b>と入力します。太字ではなく、タグがそのまま表示されれば正しく動いています。
• 推奨： ファイルのアップロードでは、種類とサイズを確認すること。また、アップロードされたファイルは、アプリのメインドメインから実行可能なページとして配信しないこと。
• 推奨： ユーザーに表示するエラーは平易にすること（「問題が発生しました」など）。詳細なエラーはサーバーのログだけに出力すること。
• 推奨： Stripeなどのサービスからのウェブフックは、処理する前にプロバイダーの署名を検証すること。ウェブフックとはをご覧ください。

すべてのフォームとAPIエンドポイントに、サーバー側の検証を追加してください。必須項目、長さ、形式、許可された値を確認します。それ以外は、わかりやすいメッセージとともに拒否します。内部のエラー詳細はユーザーに表示しないでください。

6. レート制限と不正利用

レート制限は、一定期間内に1人のユーザーが送れるリクエストの数に上限を設けるものです。レート制限がなければ、誰でも一日中パスワードを推測したり、サインアップフォームに大量に送信したり、有料APIの請求額を膨らませたりできてしまいます。

• 必須： ログイン、サインアップ、パスワードリセットには、IPアドレスごととアカウントごとのレート制限をかけること。
• 必須： 呼び出しごとに費用がかかるもの（AIモデルへのリクエスト、SMS、メール）には、ユーザーごとの上限を設け、ログインを必須にすること。
• 推奨： 公開フォーム（お問い合わせ、ウェイティングリスト）には、スパム対策を施すこと。レート制限、非表示のハニーポット項目、またはCAPTCHAのいずれかを使います。
• 推奨： 有料プロバイダーで利用上限やアラートを設定し、バグや攻撃者によって無制限の請求が発生しないようにすること。

7. 依存関係

アプリはオープンソースのパッケージで構築されていて、パッケージには既知の脆弱性が見つかることがあります。

• 推奨： AIに既知の脆弱性を確認するよう依頼し（JavaScriptのプロジェクトでは、npm auditまたはパッケージマネージャーの同等のコマンド）、影響を受けるものを更新すること。
• 推奨： アプリがもう使っていないパッケージを削除すること。
• 推奨： 利用者がとても少ないパッケージや、人気のあるパッケージの誤字のような名前のパッケージには注意すること。
• 後で： 1〜2か月ごとに再確認するか、コードをGitHubに置いている場合は自動アラートを有効にすること。

8. バックアップと復旧

セキュリティには、ミスから復旧できることも含まれます。ミスは自分によるものでも、AIによるものでも、攻撃者によるものでも構いません。

• 必須： データがどこにあり、バックアップされているかどうかを把握すること。推測せず、ホスティングサービスのドキュメントで確認してください。
• 推奨： 重要なデータを定期的に自分でエクスポートし（たとえばCSVエクスポート機能やデータベースのダンプ）、別の場所に保管すること。
• 推奨： コードをバージョン管理で管理し、どのバージョンにも戻せるようにすること。
• 推奨： 削除などの破壊的な操作（アカウントの削除、プロジェクトの削除）では確認を求めること。また、一定期間は取り消せる「論理削除」の採用も検討すること。
• 後で： 一度実際に復元をテストすること。一度も復元したことのないバックアップは、計画ではなく願望にすぎません。

9. 公開前

• 必須： 公開サイトでは、すべてのページでHTTPSを使うこと。
• 必須： 開発中のサンプルデータ、テストアカウント、デバッグ用ページを削除すること。
• 推奨： プライバシーポリシーに、収集するデータとその理由を記載すること。個人データを収集する場合、多くの地域で必須です。持っていない認証（SOC 2、HIPAAなど）を主張しないこと。
• 推奨： セキュリティ上の問題について連絡を受け付ける手段を用意し、すべてのキーを素早く再発行する方法を把握しておくこと。

セキュリティ以外も含めた公開前の広範な確認については、AIのプロトタイプを本番環境に移す方法をご覧ください。

専門家によるレビューが必要な場合

チェックリストは一般的な間違いを見つけるためのものであり、専門家の代わりになるものではありません。次のような場合は、レビューにお金をかけることを検討してください。ホスト型の決済画面を経由せず、クレジットカード番号を自分で処理する場合、健康、金融、子どもに関するデータを保存する場合、セキュリティに関する質問票を求める企業に販売する場合、または情報が漏えいすると重大な損害を受ける場合です。コードをエクスポートできる状態にしておくと、そのレビューがずっと容易になります。

Mythexでの構築とセキュリティ

Mythexにはセキュリティスキャンのパネルは含まれていないため、上記のチェックリストに沿って進めてください。役立つことをいくつか挙げます。

• プロジェクトのシークレット。 キーは、プロジェクト設定 → Secretsに保存するか、エージェントがチャットに表示するシークレットのカードから保存してください。これにより、キーがコードやメッセージに残らないようにできます。公開中のアプリでシークレットを変更したら、もう一度公開してください。
• PlanモードとAskモード。 コードを編集させずに権限を確認するようエージェントに頼みます。例：「Askモードで、すべてのAPIルートと、それぞれが行う権限チェックを一覧にしてください。」
• /test は、エージェントがユーザーとしてプレビューをクリックして操作します。セクション2の2アカウントでのテストに便利です。
• チェックポイント を使うと、問題を起こした変更を元に戻せます。

ドキュメントの自分で作ったアプリのセキュリティと環境変数とシークレットもご覧ください。次にユーザーアカウントを追加する場合は、アプリにログインを追加する方法をお読みください。

よくある質問