対象：ASP.NET Core でアプリやAPIを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）を示します。フレームワーク全体の考え方は フレームワーク別セキュリティの一覧 も参照。
優先度つきハードニング・チェックリスト
まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用で守る項目です。
P0 ── 前提（まずこれ）
本番で詳細エラー非表示 ／ 秘密を設定の外部から ／ NuGet依存CVE即パッチ
P1 ── 最頻の事故源
認可（[Authorize]・既定拒否・所有者）／ over-posting対策（DTO/[Bind]）
P2 ── 継続的な運用
安全でないデシリアライズ ／ HTTPS・ヘッダ・antiforgery ／ SSRF
| 優先 | 対策 | 具体（ASP.NET Core） |
|---|---|---|
| P0 | 本番エラー | UseExceptionHandler。開発者例外ページ/詳細を本番で出さない（環境判定を正しく） |
| P0 | 秘密の外部化 | appsettings.json に直書きしない。開発=User Secrets、本番=環境/Key Vault |
| P0 | NuGet依存CVE | dotnet list package --vulnerable/osv-scanner で監視・実稼働版で判定し即パッチ |
| P1 | 認可を明示 | [Authorize]＋既定拒否（フォールバックポリシー）＋リソースベース/所有者確認 |
| P1 | over-posting対策 | エンティティ直バインドを避けDTOへ。[Bind] で受け入れを限定 |
| P2 | デシリアライズ | BinaryFormatter を使わない。信頼できないデータを安全でない形式で復元しない |
| P2 | HTTPS/ヘッダ/CSRF | UseHttpsRedirection・UseHsts・antiforgery（CSRF）・Cookie属性 |
| P2 | SSRF | サーバー側の外部取得は許可先限定＋内部IP/メタデータ遮断 |
1. 本番エラーの露出防止（P0）
- 本番では
UseExceptionHandler等で汎用エラーに切り替え、開発者例外ページ/詳細を出さない（ASPNETCORE_ENVIRONMENT=Production等の環境判定を正しく）。 - スタックトレースや内部構造を外部に出さない。
2. 秘密の外部化（P0）
- 接続文字列やキーを appsettings.json に直書きしない。開発は User Secrets、本番は環境変数やクラウドの秘密管理（Key Vault 相当）から読み込む。
- appsettings.json は誤コミット/公開で漏れやすい。リポジトリにコミットしない、公開ディレクトリに置かない（→ 公開ディレクトリに秘密を置かない）。万一漏れたら速やかにローテーション。
3. NuGet依存のCVE（P0）
dotnet list package --vulnerableや osv-scanner で既知CVEを機械監視し、実稼働版で判定して即パッチ（→ 依存のCVE監視 ／ CVE対応の実務）。- .NET をサポート対象バージョンに保ち、EOL版を放置しない。
4. 認可（P1・最多の事故源）
やりがち（危険）
- エンドポイントに
[Authorize]の付け忘れ - 認証はあるが所有者確認が無い
- 既定が『許可』寄りで、未認証のリクエストが通ってしまう
- ロール/ポリシーを設計せず散発的に判定
正しい
[Authorize]＋フォールバックポリシーで既定拒否- ロール/ポリシーベース＋リソースベース認可で所有者確認
- 取得・更新・削除のすべての経路で確認
- 認可は明示的に組み立て、既定任せにしない
用語は IDORとは。認証と認可は別物で、認可はデータに近い場所で確認します。
5. over-posting（過剰バインド）（P1）
- エンティティを直接バインドしない。入力専用のDTOにバインドし、必要なフィールドだけを受け入れる。
- または
[Bind]で受け入れフィールドを明示的に限定する。権限フラグ等を外部入力から上書きさせない。
6. 安全でないデシリアライズと入力（P2）
BinaryFormatterを使わない（非推奨/危険）。信頼できないデータを安全でない形式で復元しない（条件次第でRCEに繋がり得る）（→ RCEとは）。- 入力は**モデル検証（データ注釈等）**で型・範囲・許可値を検証してから使う。
7. HTTPS・ヘッダ・antiforgery（P2）
UseHttpsRedirection＋UseHstsでHTTPSを強制し、Cookie を secure/httponly/samesite に。- フォーム/状態変更には **antiforgery トークン（CSRF対策）**を用いる（→ CSRFとは）。
- セキュリティヘッダを付与（自サイトは セキュリティヘッダ診断 で確認）。
8. SSRF とサーバー側の外部取得（P2）
- サーバー（
HttpClient等）がユーザー指定URLを取得する処理は許可先を限定し、内部IP/メタデータへの到達を遮断する（→ SSRFとは）。アップロードは検証し公開面の外に保存する。
検証：自分のASP.NET Coreは固められているか
作ったら終わりではありません。点検して初めて完了です。以下は自分の環境に対する防御的な自己チェックです。
本番で開発者例外ページが出ないか
秘密が設定/リポジトリに無いか
appsettings.json に接続文字列/キーが直書きされていないこと、リポジトリに秘密が含まれないことを確認。認可が効くか
依存とHTTPS/ヘッダ
dotnet list package --vulnerable/osv がクリーンか、ヘッダ診断で HTTPS/HSTS 等が付くかを確認。当サイトの視点：安定したフレームワークでも、設定と認可は自分の責任
ASP.NET Coreは認証・認可・データ保護の仕組みが整っていますが、本番の設定と認可の付与だけは、環境ごと・エンドポイントごとに自分で正しく決める必要があります。当サイトは別スタックですが原則は同じです。本番で内部情報を出さない、秘密を設定の外部に置く、公開しているエンドポイントには必ず認可を書き、依存はCVE監視する。フレームワークの安全機能は、正しい設定と明示的な認可があって初めて役に立ちます。
次に読む
- 一覧：フレームワーク別セキュリティ（一覧） ／ Spring Bootのセキュリティ対策（同じ企業向け・依存/認可の注意点が近い）
- 実務：脆弱性(CVE)対応の実務 ／ 依存のCVE監視 ／ 公開ディレクトリに秘密を置かない
- 用語：IDORとは ／ RCEとは ／ CSRF ／ SSRF
- ツール：セキュリティヘッダ診断
出典と確認範囲
以下は上記の設定・影響範囲・対策を確認するための原典です。2026年10月23日に参照先を確認しました。各版・構成の条件は原典で確認してください。チェックリストの優先順位や教訓は当サイトの整理であり、記事全体の再検証や安全性の保証を意味しません。