secure

セキュリティ

コードベースのセキュリティ監査を実施し、重要な問題から修正します。AI で構築されたアプリで問題が起きる箇所には、いくつかの決まったパターンがあります。該当箇所を確認し、各指摘を実証してから修正してください。

ステップ 1：アプリの構成を把握する

コードを読み、以下を簡潔にまとめてください。

• フレームワークと、サーバーコードが実行される場所
• データベースと、ブラウザーからデータベースに直接アクセスするかどうか
• ユーザーのログイン方法
• すべての API ルート、サーバーアクション、Webhook エンドポイント
• アプリが使用するすべてのサードパーティーのキー
• 費用がかかるすべての呼び出し：AI モデル、メール、SMS

ステップ 2：被害の大きい問題から順に確認する

1. シークレット

• コードと Git の履歴から、キーやパスワードを検索します。
• .env ファイルが .gitignore に含まれていることを確認します。
• ブラウザーに渡されるすべての環境変数を列挙します。ほとんどのフレームワークでは、公開用のプレフィックスが付いています。これらにシークレットを含めてはいけません。
• アクセスルールを回避できるデータベースキー（管理者キーやサービスキー）をブラウザーに渡してはいけません。
• 一度でもコミットされたシークレットはローテーションが必要です。ファイルを削除しても、Git の履歴からは消えません。

2. データの分離：ある顧客が別の顧客のデータを見ることはできない

• 顧客データを返すすべてのクエリは、サーバー上でログイン中のユーザーまたはアカウントによって絞り込む必要があります。
• ブラウザーからデータベースに直接クエリを送る場合、データベース自体のアクセスルールが、すべてのテーブルに対する読み取り、作成、更新、削除を網羅している必要があります。
• 実証してください： アカウントを 2 つ作成します。アカウント A から、URL または API 呼び出しの ID を変更して、B のレコードをリクエストします。リクエストは失敗しなければなりません。これは AI で構築されたアプリで最も被害の大きいバグであり、通常の利用では気づけません。

3. すべてのルートで認証を確認する

• すべてのルートとサーバーアクションで、ユーザーがログインしていることを確認します。
• すべてのルートとサーバーアクションで、操作対象のオブジェクトをユーザーが所有していることを確認します。
• 管理者ページでは、サーバー上でユーザーのロールを確認します。リンクを非表示にするだけでは保護になりません。

4. 決済と Webhook

• Webhook エンドポイントは、処理を実行する前に署名を検証します。
• 有料アクセスは、検証済みの Webhook によってのみ付与します。ブラウザーで読み込まれる「ありがとうございます」ページから付与してはいけません（決済を参照）。

5. 不正利用とコスト

• ログイン、サインアップ、パスワードリセット、および費用がかかるすべてのエンドポイントにレート制限を設けます。
• AI 呼び出しにはユーザーごとの 1 日あたりの上限を設定し、AI プロバイダー側にも支出上限またはアラートを設定します。公開状態の AI エンドポイントを 1 つのスクリプトから叩くだけで、ひと晩に、事業が 1 か月で稼ぐ額を超える費用が発生することがあります。

6. 入力と出力

• サーバー上で入力を検証します。
• パラメーター化クエリまたは ORM を使い、ユーザー入力から組み立てた文字列は決して使いません。
• ユーザー入力を生の HTML としてレンダリングしてはいけません。
• アップロードされたファイルの種類とサイズを確認します。

7. 依存関係 パッケージマネージャーの監査コマンドを実行します。重大度が高または緊急の指摘事項を修正します。

8. エラーとログ

• ユーザーにスタックトレースを見せてはいけません。
• ログにパスワード、トークン、カード番号、または必要以上の個人データを含めてはいけません。

ステップ 3：規制対象データの確認

アプリが健康記録、金融口座データ、子どものデータ、または学生記録を保存している場合は、作業を中断し、特別な規則が適用されることを創業者にはっきりと伝えます。たとえば、米国の健康データを扱う場合、そのデータを保存するすべてのホスティング事業者と署名済みの契約を結ぶ必要があります。ローンチ前に専門家によるレビューを受けることを勧めてください。このチェックリストだけでは、そのようなデータを十分に保護できません。

ステップ 4：修正する

創業者の承認を得て、重大な指摘事項をすぐに修正します。修正のたびに、問題を検出したチェックを再実行します。残りの指摘事項は、それぞれに平易な言葉でリスクを添えて列挙します。

ルール

• 報告する前に、各指摘を実証してください。 証拠のない指摘は創業者の時間を無駄にし、指摘を無視するよう促すことになります。
• 広く知られた認証ライブラリまたはサービスを使います。 パスワードの保存やセッション管理を一から作ってはいけません。
• 今は不要です： 有料の侵入テスト（機密データを扱う、またはユーザー数が約 1,000 人になるまで待つ）、シングルサインオン（顧客から要望があるまで待つ）、Web アプリケーションファイアウォール（基本的な対策はホスティング事業者がカバーします）。

出力

| Severity | Finding | Where (file:line) | Proof | Fix | Status |

深刻度：Critical（データや金銭が今すぐ漏えいする可能性があります）、High（悪用される可能性が高いです）、Low（都合のよいときに修正してください）。有料顧客にアプリを提供しても安全かどうかを、最後に1文で述べてください。