secure-coding

セキュアコーディング

一般的な Web フレームワークで安全なコードを記述・レビューするためのスキルです。各フレームワークには、そのフレームワークに適した安全なパターンと、特有の落とし穴があります。OWASP の一般的なアドバイスだけでは不十分なため、フレームワーク固有のガイダンスを適用してください。

適用するタイミング

以下の言語またはフレームワークで作業する場合に、このスキルを適用してください。

参照	言語 / フレームワーク
references/java-spring.md	Java Spring / Spring Boot
references/python-django.md	Python Django
references/python-flask.md	Python Flask
references/python-fastapi.md	Python FastAPI
references/ruby-on-rails.md	Ruby on Rails
references/react.md	React（Next.js を含む）
references/vue.md	Vue（Nuxt を含む）
references/angular.md	Angular
references/go.md	Go（net/http、Gin、Echo、Fiber、Chi）
references/aspnet.md	ASP.NET（Core、MVC、Web API、Razor、Blazor）
references/c.md	C（C99～C23、システム／組み込み／カーネル周辺）
references/cpp.md	C++（C++17/20/23）
references/typescript.md	TypeScript（Node/Express/NestJS/Fastify/Deno/Bun ＋ 共通フロントエンド）
references/csharp.md	C# 言語（Web 以外のコンテキスト — コンソール、サービス、デスクトップ、ライブラリ）
references/terraform.md	Terraform / OpenTofu（AWS、Azure、GCP IaC）

ワークフロー

1. 対象となる言語／フレームワークを特定します。 package.json、tsconfig.json、pom.xml、build.gradle、requirements.txt、Pipfile、pyproject.toml、Gemfile、go.mod、*.csproj、*.sln、Makefile／CMakeLists.txt、*.tf／*.tfvars、または対象ファイル内のインポート文や拡張子を確認してください。複数が該当する場合（例：Terraform でデプロイされる、React＋TypeScript のフロントエンドと Django のバックエンド）、関連する参照ファイルをそれぞれ読み込んでください。
2. 関連する参照ファイルのみを読み込みます。 各参照ファイルは単独で完結しており、そのフレームワークでよくあるセキュリティ上の落とし穴と、そのフレームワークに適した安全なパターンを説明しています。
3. 変更内容に合わせてガイダンスを適用します。 PR にチェックリスト全体を記載するのではなく、変更が実際に関係する項目に絞ってください（例：JSON を受け付ける新しいエンドポイントなら、入力検証、認証／認可、出力エンコーディング。新しいファイルアップロードなら、保存先パス、コンテンツタイプ、サイズ制限）。
4. コードをレビューする際は、変更箇所を参照ファイルの「レビュー用チェックリスト」に沿って確認し、具体的な問題をファイル名と行番号で示し、修正案を提示してください。
5. 新しいコードを記述する際は、独自の方法を考案するのではなく、参照ファイルにある「安全なパターン」のスニペットを優先してください。

各リファレンスの対象範囲

Web フレームワークのリファレンス（Spring、Django、Flask、FastAPI、Rails、React、Vue、Angular、Go、ASP.NET）は、共通のカテゴリを中心に構成されています。

• インジェクション — SQL、NoSQL、コマンド、LDAP、テンプレート、ヘッダーのインジェクション
• 認証／認可 — ログインフロー、セッション／Cookie の設定、パスワードの保存、ロールの確認、IDOR
• CSRF — 該当する状況、フレームワークのデフォルト設定、誤って無効化してしまう一般的な方法
• XSS／出力エンコーディング — 自動エスケープのデフォルト設定と、安全に回避する方法と危険な回避方法
• CORS — 制限的なデフォルト設定、よくある設定ミス
• シークレットと設定 — シークレットを保存すべき場所と避けるべき場所、フレームワーク固有の設定上の落とし穴
• 暗号 — フレームワークが提供する機能と、自前で実装すべきでないもの
• ファイルアップロードとパストラバーサル — 安全な保存方法、コンテンツタイプの処理、ファイル名のサニタイズ
• デシリアライズ — 安全なパーサー、危険な形式（Pickle、Marshal、BinaryFormatter、ObjectInputStream、YAML.load）
• SSRF — 外部への HTTP 呼び出し、URL フェッチャー、Webhook
• セキュリティヘッダー — CSP、HSTS、X-Frame-Options、Referrer-Policy、フレームワーク固有のヘルパー
• ログとエラー処理 — ログに記録すべき内容、記録してはいけない内容（PII、シークレット、トークン）、スタックトレースの露出
• 依存関係 — 既知の脆弱なバージョン、アドバイザリデータベースへのリンク、アップグレード手順
• フレームワーク固有の落とし穴 — 経験豊富な開発者でさえ陥りやすい問題

言語リファレンスでは、フレームワークを超えて共通する問題に焦点を当てています。

• C／C++ — メモリ安全性（バッファ／ヒープオーバーフロー、UAF、二重解放）、整数オーバーフロー／アンダーフロー、フォーマット文字列、文字列／パス API、TOCTOU、system／exec 経由のコマンドインジェクション、暗号ライブラリの使用方法、コンパイラの強化（-D_FORTIFY_SOURCE、スタックプロテクター、ASAN／UBSAN／ファジング）
• TypeScript — 型安全性はコンパイル時のみ保証されること、信頼境界での実行時検証（Zod／Valibot／class-validator）、厳格な tsconfig.json、any と unknown の使い分け、Node 固有のトピック（Express／NestJS／Fastify のミドルウェア、プロトタイプ汚染、eval／vm／Function(str)、サプライチェーン）
• C#（非 Web） — Process.Start の argv 処理、暗号 API の使用方法（RNG、ハッシュ、AEAD）、シリアライズの危険性（BinaryFormatter、Newtonsoft.Json の TypeNameHandling）、XML エンティティの強化、シークレットの消去、HttpClient の TLS、リフレクション／CSharpScript による RCE の攻撃対象領域、ReDoS
• Terraform — .tf／状態ファイル内のシークレット、パブリックリソースの設定ミス（S3、セキュリティグループ、ファイアウォール）、IAM のワイルドカードと信頼ポリシーの Condition ブロック、保存時／転送時暗号化のデフォルト設定、モジュール／プロバイダーのバージョン固定、危険なプロビジョナー、CI でのポリシー・アズ・コード（tfsec、checkov、trivy config）

リファレンスの使い方

• 対象を絞ったタスク（例：「このログインコントローラーをレビューする」）では、リファレンスを 1 つ読み込み、該当するセクションを検索してください。
• 広範囲なレビュー（例：「この Spring Boot サービスを監査する」）では、リファレンスを読み込み、末尾のチェックリスト全体に沿って確認してください。
• 複数のスタックを使うアプリ（例：React + FastAPI）では、両方を読み込んでください。フロントエンドとバックエンドのセキュリティ上の懸念は完全には重ならないことが多く、CSRF、CORS、認証トークンの保存はいずれも両者の境界に関わります。

レビューの出力スタイル

コードをレビューするときは、指摘事項を次のようにまとめてください。

[Severity] <Category> — <file>:<line>
What: <one-sentence description of the issue>
Why it matters: <concrete impact>
Fix: <minimal code change or pattern reference from the framework guide>

重大度の基準：Critical（RCE、認証の回避、大規模なデータ漏えい）／High（権限昇格、IDOR、保存型 XSS）／Medium（反射型 XSS、状態変更を伴う CSRF、情報漏えい）／Low（多層防御の不足、強化の不備）。

問題のない確認項目で報告書を水増ししないでください。問題点、不足している点、および対処方法を記載してください。

言語／フレームワークがリストにない場合

ユーザーが対象外の言語やフレームワーク（Rust、Kotlin、Phoenix、Laravel、NestJS、Pulumi、CloudFormation など）を使用している場合は、最も近い類似例を適用し、類推に基づいていることをユーザーにはっきり伝えて、フレームワーク固有の動作を確認できるようにしてください。大まかな類似例は次のとおりです。

• Rust ≈ unsafe ブロック／FFI については C/C++。それ以外はデフォルトでメモリ安全です — unsafe、暗号化クレートの使用（RustCrypto／ring）、Web フレームワーク固有の点（Axum／Actix）に重点を置いてください。
• Kotlin (JVM) ≈ Spring Boot／Ktor については java-spring.md。Java と同じ暗号化とシリアライゼーションの落とし穴があります。
• NestJS ≈ 言語レイヤーには typescript.md ＋ angular.md 形式の DI／デコレーターパターン。
• Phoenix (Elixir) ≈ ruby-on-rails.md — デフォルト設定（CSRF 保護、パラメーターのバインディング）は似ていますが、イディオムは異なります。
• Laravel (PHP) ≈ ruby-on-rails.md — MVC と、設定より規約を重視するセキュリティのデフォルト設定が類似しています。
• Pulumi / CloudFormation / Bicep ≈ terraform.md — IaC に関する懸念（シークレット、状態、パブリックリソース、IAM）は共通です。