対象：ASP.NET Core でアプリやAPIを運営している人。ここでは攻撃手順は扱わず、堅い基盤を活かしつつ、設定で開く穴を塞ぐ方法を解説します。全体像は フレームワーク別セキュリティの入口 も参照。
三大落とし穴（設定で開く）
ASP.NET Coreの仕組みは優秀ですが、次の3つは設定と作り込みで守る領域です。
① 本番の詳細エラー露出
開発者例外ページ等で内部情報が露出。故意のエラーで抜かれる。
② appsettingsへの秘密
接続文字列・キーを直書き。誤コミット/公開で漏えい。
③ 認可属性の付け忘れ
[Authorize]漏れで誰でも到達。所有者確認も無し。
そのほか、BinaryFormatter 等の安全でないデシリアライズ、モデルバインディングの過剰受け入れ（over-posting）、NuGet依存の既知CVE放置も注意点です。
塞ぎ方（3ステップ）
本番は詳細エラーを非表示に
秘密は設定の外部から読み込む
認可を明示し、危険な入力経路を断つ
[Authorize]と所有者確認を明示（既定は拒否側に）。over-postingはDTOや[Bind]で受け入れフィールドを制限し、信頼できないデータを安全でない形式でデシリアライズしない。NuGet依存はCVE監視＋即パッチ（→ IDORとは）。やりがち（危険）
- 本番で開発者例外ページを露出
appsettings.jsonに秘密を直書き[Authorize]付け忘れ・所有者確認なし- モデルに全フィールド受け入れ（over-posting）
正しい
- 本番は詳細エラー非表示
- 秘密はUser Secrets/環境/Key Vault
- 認可を明示（既定拒否・所有者確認）
- DTO/[Bind]で受け入れ制限
当サイトの視点：堅い基盤でも『設定と認可』は自分の責任
ASP.NET Coreは認証・認可・データ保護の仕組みが整っていますが、本番の設定と認可の付与だけは、環境ごと・エンドポイントごとに自分で正しく決める必要があります。当サイトは別スタックですが原則は同じ——本番で内部情報を出さない、秘密を設定の外部に置く、公開入口には必ず認可を書く、依存はCVE監視する。堅い基盤の価値は、正しい設定と明示的な認可があって初めて発揮されます。
次に読む
- 入口：フレームワーク別セキュリティ（入口） ／ Spring Bootのセキュリティ対策（同じ企業系・依存/認可の型が近い）
- 秘密：公開ディレクトリに秘密を置かない ／ 実務：脆弱性(CVE)対応の実務
- 用語：IDORとは ／ RCEとは
よくある質問
QASP.NET Core は安全ですか？
ASP.NET Core は成熟した堅い基盤で、認証・認可・データ保護（Data Protection）などの仕組みが整っています。正しく使えば強力ですが、事故は本体でなく設定で起きます。とくに本番での詳細エラー露出、appsettingsへの秘密直書き、認可属性の付け忘れは、フレームワーク特有というより設定・運用の問題として繰り返し起きます。
Q秘密（接続文字列やAPIキー）はどこに置くべきですか？
appsettings.json にそのまま書かないのが原則です。開発では User Secrets、本番では環境変数やクラウドの秘密管理（例：Key Vault 相当）から読み込みます。appsettings.json はリポジトリに入りやすく、公開ディレクトリや誤コミットで漏れやすいためです。万一漏れたら接続文字列やキーを速やかにローテーションしてください。
Q認可属性の付け忘れはどう防ぎますか？
コントローラやエンドポイントに [Authorize] を付け忘れると、認証を通さず誰でも到達できてしまいます。既定を『拒否』側に寄せる（フォールバックポリシーで未認証を弾く）、ロール/ポリシーベースで権限を明示する、リソース所有者の確認を書く、といった設計にします。『ログインしていれば実行可』で止めず、操作対象の所有者まで確認するのが安全です。