フレームワーク別

ASP.NET Coreのセキュリティ対策 — 本番ハードニング実務リファレンス

ASP.NET Coreを安全に運用するための実務リファレンス。優先度つきハードニング・チェックリスト、本番エラーの露出防止・秘密の外部化(User Secrets/環境/Key Vault)・NuGet(依存)のCVE・認可([Authorize]/既定拒否/所有者)・over-posting・デシリアライズ・HTTPS/ヘッダ/CSRF・SSRFの各対策、そして自己検証まで。攻撃手順は載せず防御と点検のみ。

公開日 2026-07-02 更新日 2026-07-02 9分で読める

対象：ASP.NET Core でアプリやAPIを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）を示します。フレームワーク全体の考え方はフレームワーク別セキュリティの入口も参照。

優先度つきハードニング・チェックリスト

まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用衛生です。

P0 ── 前提（まずこれ）

本番で詳細エラー非表示／秘密を設定の外部から／ NuGet依存CVE即パッチ

P1 ── 最頻の事故源

認可（[Authorize]・既定拒否・所有者）／ over-posting対策（DTO/[Bind]）

P2 ── 運用衛生

安全でないデシリアライズ／ HTTPS・ヘッダ・antiforgery ／ SSRF

ハードニングは土台から積む。P0（前提）→P1（最頻の事故源）→P2（運用衛生）。

優先	対策	具体（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
ツール：セキュリティヘッダ診断

よくある質問

QASP.NET Coreで最初にやるべきセキュリティ対策は何ですか？

優先度P0の3つです。(1)本番で開発者例外ページ/詳細エラーを出さない（UseExceptionHandler・環境判定を正しく）、(2)秘密を appsettings.json に直書きせず外部化する（開発は User Secrets、本番は環境変数やKey Vault等）、(3)NuGet依存のCVEを機械監視し実稼働版で判定して即パッチ。次に認可([Authorize]・既定拒否)と over-posting 対策へ進みます。

Q秘密（接続文字列やAPIキー）はどこに置くべきですか？

appsettings.json にそのまま書かないのが原則です。開発では User Secrets、本番では環境変数やクラウドの秘密管理（Key Vault 相当）から読み込みます。appsettings.json はリポジトリに入りやすく、公開ディレクトリや誤コミットで漏れやすいためです。万一漏れたら接続文字列やキーを速やかにローテーションしてください。

Q認可属性の付け忘れはどう防ぎますか？

コントローラやエンドポイントに [Authorize] を付け忘れると、認証を通さず誰でも到達できます。既定を『拒否』側に寄せ（フォールバックポリシーで未認証を弾く）、ロール/ポリシーベースで権限を明示し、リソースの所有者確認（リソースベース認可）を書きます。『ログインしていれば実行可』で止めず、操作対象の所有者まで確認するのが安全です。

Qover-posting（過剰バインド）とは何ですか？

モデルバインディングでエンティティに全フィールドを受け入れると、ユーザーが送った想定外のフィールド（権限フラグ等）まで上書きされ得ます。これが over-posting です。対策は、入力専用のDTOにバインドする、または [Bind] で受け入れフィールドを明示的に限定することです。エンティティを直接バインドしないのが安全です。

Q安全でないデシリアライズはなぜ危険ですか？

BinaryFormatter のような安全でないデシリアライザで信頼できないデータを復元すると、条件次第でリモートコード実行(RCE)に繋がり得ます。BinaryFormatter は非推奨/危険とされており使わないこと。外部由来のデータは由来を検証し、必要なら安全な形式（例：適切に設定した JSON）に限定します。