specsfy-specialist-application-security

アプリケーションセキュリティ

使用する場面

• 変更によって信頼境界、アイデンティティ、外部入力（アップロード、URL、クエリ、デシリアライズ）、または機密データに影響が及ぶ場合に使用します。
• 新たな攻撃対象領域を持つ機能（新しい公開エンドポイント、新しい連携、新しいユーザー種別）を設計する前にも使用し、事前に脅威モデリングを行います。
• パイプライン／デプロイの認証情報のレビューの代わりとしては使用しません。その場合は $specsfy-specialist-delivery-engineering を使用してください。ここではデリバリーパイプラインではなく、アプリケーションとそのデータに焦点を当てます。
• リスクが行単位またはテナント単位のデータアクセスのモデリングに関わる場合は、$specsfy-specialist-postgres／$specsfy-specialist-supabase と組み合わせます。

手順

1. 制御方法を検討する前に、資産、アクター、信頼境界、外部入力、影響（状態がどのように変化するか）を把握します。
2. 制御を選択する前に、現実的な脅威とその実際の影響を定義します。システムのコンテキストに存在しない脅威に対する防御は実装しません。
3. データを読み取る、または変更するすべての操作について、認証、オブジェクト単位の認可（ルート単位だけではありません）、テナントの分離を確認します。
4. すべての入力を想定する型、サイズ、用途に照らして検証します。レンダリングのコンテキストに応じて出力を正規化し、該当する場合は変更操作をリプレイや CSRF から保護します。
5. シークレット管理、通信時および保存時の暗号化、セッションのライフサイクル、脆弱な依存関係、本番環境の設定をレビューします。
6. 特定した重要な境界について、肯定的なテスト（認可されたフローが機能する）と否定的なテスト（認可されていないフローが失敗する）を用意します。
7. 残存リスク、担当者、関連する可観測性の指標、対応計画を記録します。どのシステムも「100％安全」にはなりません。リスクを把握し、監視できる状態にすることが重要です。

パターン

• デフォルトで拒否し、各アイデンティティと操作に必要最小限の権限を付与します。
• すべての操作とアクセス対象のすべてのオブジェクトについて、サーバー側で認可します。クライアント側だけのチェックや、所有権／テナントを再検証せずにクライアントから渡されたオブジェクト ID を信頼してはいけません。
• ファイルアップロード、ユーザーが指定した URL、外部データを含むレンダリング済みテンプレート、動的クエリ、外部データのデシリアライズは、デフォルトで悪意のある入力として扱います。
• 独自の暗号化を実装せず、確立されたプリミティブとライブラリを使用します。デバッグ環境であっても、シークレット、トークン、パスワード、機密データをログに記録してはいけません。
• 認証情報を定期的にローテーションし、長期間有効な静的シークレットよりも一時的なアイデンティティ（有効期間の短いトークン、STS/OIDC）を優先します。
• アクター単位およびリソース単位の制限（ユーザー／API キー／テナント単位のレート制限）を設けて不正利用を軽減します。IP 単位だけの制限では不十分です。共有 IP（NAT、プロキシ）は正規のユーザーに不利益を与え、分散した攻撃者は IP 単位だけの制限を回避できます。
• 脆弱性を修正する際は、根本原因を解消して回帰テストを追加します。修正または検証を行う必要がある人に必要な範囲を超えて、悪用の詳細を公開してはいけません。

アンチパターン

• ルート（/admin/* が保護されているかどうか）だけで認可を確認し、ルート内でアクセスされる特定のオブジェクトを確認しないこと：テナント A として認証されたユーザーが、URL の ID を変更するだけで、テナント B の /api/orders/123 にアクセスできてしまいます（IDOR — Insecure Direct Object Reference）。
• クライアント（ブラウザー内の JavaScript）だけで入力を検証し、サーバーで再検証しないこと：API への直接リクエストで、クライアント側の検証を完全に回避できます。
• アップロードの処理方法を決める際に、クライアントが申告した Content-Type やファイル拡張子を信頼すること：悪意のあるファイルを無害な種類のファイルに偽装できてしまいます。
• アプリケーションのシークレット（API キー、データベースのパスワード）を、プロセスやログへのアクセス制御がないまま環境変数に保存すること、または認証トークンを含むリクエストのペイロード全体をログに記録すること：元の「保管庫」が適切でも、間接的な経路からシークレットが漏えいします。
• 元の攻撃経路がもはや機能しないことを証明する、具体的なネガティブテストなしに「システムは安全です」や「脆弱性を修正しました」と発表すること。

検証

• ネガティブテストケース：認証なし、誤った ID でのアクセス、誤ったテナントでのアクセス、処理済みリクエストの再送をすべて、制御された形で失敗させる必要があります。
• プロジェクトですでに採用されているツールを使って、脆弱な依存関係を分析し、漏えいしたシークレットをスキャンします。大規模なリリース前に手動で行うだけでなく、通常のフローの一部として実行してください。
• 安全な本番環境の設定：セキュリティヘッダー（例：Content-Security-Policy、Strict-Transport-Security）、Cookie 属性（HttpOnly、Secure、SameSite）、および実際に必要なオリジンだけに制限した CORS ポリシーを設定します。
• 主張する各制御と残存リスクを示す具体的な証拠を用意します。証明するテストなしに、絶対的な表現で何かを「安全」と宣言してはいけません。

関連するスキル

• $specsfy-specialist-ansible と $specsfy-specialist-docker は、ホスト、コンテナー、ランタイムのハードニングを実施します。このスキルでは、設定によって証明すべき脅威、権限、制御を定義します。
• $specsfy-specialist-laravel、$specsfy-specialist-nextjs、$specsfy-specialist-shadcn-ui は、アプリケーションの各種インターフェースを実装します。認可、サーバー側の検証、データの露出は引き続きこのスキルの対象です。
• $specsfy-specialist-code-review は包括的なレビューを行い、$specsfy-specialist-observability は機密データを漏えいさせずに不正使用の兆候を記録します。
• $specsfy-specialist-postgres と $specsfy-specialist-supabase は、データレベルでの行／テナント単位の認可モデル（RLS、制約）を扱います。
• $specsfy-specialist-delivery-engineering は、パイプラインの認証情報、アーティファクトへの署名、サプライチェーンのハードニングを扱います。
• $specsfy-specialist-web-api-design は、API コントラクトの設計（動詞、バージョニング、機密フィールドの露出）に起因するリスクを扱います。

references/standards.md を参照してください。境界ごとの脅威モデリング、ASVS、API セキュリティ、サプライチェーンに関するチェックリストと一次情報源が記載されています。