フレームワーク
このタグの記事 9 件
ASP.NET Coreのセキュリティ対策 — 本番エラー・秘密・認可の守り方
ASP.NET Coreは成熟した堅い基盤だが、事故は設定で起きる。三大＝(1)本番で詳細エラー/開発者例外ページを露出（内部情報漏れ）(2)appsettings.jsonへの秘密直書き（user-secrets/環境変数/Key Vaultを使う）(3)認可属性（[Authorize]）の付け忘れ。加えてBinaryFormatter等の安全でないデシリアライズ、モデルバインディングの過剰受け入れ（over-posting＝DTO/[Bind]で制限）、NuGet依存のCVE。守り＝本番は詳細エラー非表示・秘密は設定外部から・認可を明示。
Djangoのセキュリティ対策 — DEBUG・SECRET_KEY・認可の守り方
Djangoは『バッテリー同梱』で安全な既定（ORM・CSRF・テンプレート自動エスケープ・認証）を備え、正しく設定すれば堅い。だが事故は設定で起きる。三大＝(1)本番でDEBUG=True＝エラー画面に設定・環境変数・秘密が露出(2)SECRET_KEYの漏えい（署名・セッションの土台）(3)認可の作り込み不足（is_staff/権限チェック漏れ）。加えてraw()/extra()や文字列連結によるSQLi、pickle等の安全でないデシリアライズ、ALLOWED_HOSTS未設定、依存(pip)のCVE。守り＝本番DEBUG=False・SECRET_KEYを環境から・認可を明示。
Express（Node.js）のセキュリティ対策 — 守りは『自分で足す』
Expressは最小主義＝既定ではセキュリティ機能をほぼ持たない。ゆえに守りは開発者が『自分で足す』。要点＝(1)セキュリティヘッダ（helmet相当）(2)入力の検証とサニタイズ(3)認証だけでなく所有者スコープの認可(4)レート制限（総当り・DoS対策）(5)依存パッケージ(npm)のCVE監視＋即パッチ。加えて外部URL取得はSSRF対策、秘密はenvでコード非混入。最小の自由と引き換えに、防御の責任も自分にある。
フレームワーク別セキュリティ対策 — 使っている技術ごとの守り方
フレームワークが変わっても、突かれる弱点の“型”（アクセス制御・秘密の扱い・インジェクション・依存CVE・設定ミス）はほぼ共通。違うのは『既定の危険な設定』と『その技術でよく狙われる場所』。当サイトは各フレームワークの“デフォルトの落とし穴”と“ハードニング手順”を1つずつ用意する。まずは自分が使っているフレームワークの章へ。
Laravelのセキュリティ対策 — .env露出・APP_DEBUG・認可の守り方
Laravelは既定値が比較的安全な一方、事故のほとんどは運用面から起きる。三大落とし穴＝(1).envや秘密ファイルが公開ディレクトリ(public)からURLで取得できる、(2)本番でAPP_DEBUG=trueのまま＝エラー画面に環境変数・接続情報が露出、(3)認可漏れ（ログイン＝認証はあるが所有者スコープの認可が無い／Mass Assignmentで想定外フィールド上書き）。守り＝秘密をpublicの外＋権限600・本番はdebug off＋設定キャッシュ・Policy/Gateで認可・$fillableを明示。
Next.jsのセキュリティ対策 — Server Actions・環境変数・依存CVEの守り方
Next.jsは既定が安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。三大＝(1)環境変数の露出（NEXT_PUBLIC_ の誤用やサーバー専用の秘密をクライアントへ渡す）(2)Server Actions / Route Handlers の認可漏れ（認証はあるが所有者スコープが無い）(3)依存パッケージの既知CVE（フレームワーク本体のRCEを含む・実稼働版で判定し即パッチ）。守り＝秘密はサーバー限定・境界を意識・Server Actionsで認可を毎回確認・依存CVEを機械監視。
Ruby on Railsのセキュリティ対策 — Strong Parameters・認可・gem CVEの守り方
Railsは規約と安全な既定（CSRF保護・Strong Parameters・ORM）を備え、正しく使えば堅い。だが事故は運用で起きる。三大＝(1)Strong Parametersを緩め過ぎてMass Assignment（is_admin等の想定外上書き）(2)認可の作り込み不足（ログイン＝認証はあるが所有者スコープが無い）(3)gem（依存）の既知CVE。加えてwhereへの文字列連結によるSQLi、send/constantize等の危険な動的メソッド、credentials/secret_key_baseの漏えい。守り＝permitを絞る・認可を明示・gemをCVE監視。
Spring Bootのセキュリティ対策 — 依存CVE・Actuator露出・認可の守り方
Spring（Spring Boot）はエンタープライズ定番。事故の型＝(1)依存ライブラリの既知CVE（Log4Shellのように広く継承される土台の穴・実稼働版で判定し即パッチ）(2)Actuatorなど管理/診断エンドポイントの露出（情報漏れ・操作）(3)Spring Securityの認可設定漏れ（認証はあるが権限チェックが緩い）(4)安全でないデシリアライズ。守り＝依存CVEを機械監視して即パッチ・Actuator/管理面を絞る・認可を明示・信頼できないデータをデシリアライズしない。
WordPressのセキュリティ対策 — 狙われる理由と最低限の守り方
WordPressは世界最大シェア＝統計的に最大の標的。事故の入口は本体のバグより『プラグイン/テーマの脆弱性・放置更新・弱い/使い回しの管理者・露出した管理画面(wp-admin/xmlrpc/REST列挙)』。守り＝本体とプラグインの更新を自動化・使わないプラグイン/テーマは削除・管理者に強いパスワード＋2FA・管理画面の露出とログイン試行を絞る・改ざん検知とオフラインバックアップ。