フレームワーク
このタグの記事 9 件
Djangoのセキュリティ対策 — 本番ハードニング実務リファレンス
Djangoは『バッテリー同梱』の安全な既定(ORM・CSRF・自動エスケープ・認証)を備えるが、事故は設定から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝本番DEBUG=False＋ALLOWED_HOSTS・SECRET_KEYの外部化・pip依存CVE・本番セキュリティ設定(SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE等)・認可(所有者スコープ)・インジェクションと出力(raw/extra・mark_safe)・CSRF/セッション/管理画面・SSRF/アップロード (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
フレームワーク別セキュリティ対策 — 使っている技術ごとの守り方
フレームワークが変わっても、突かれる弱点の“型”（アクセス制御・秘密の扱い・インジェクション・依存CVE・設定ミス）はほぼ共通。違うのは『既定の危険な設定』と『その技術でよく狙われる場所』。当サイトは各フレームワークの“デフォルトの落とし穴”と“ハードニング手順”を1つずつ用意する。まずは自分が使っているフレームワークの章へ。
Laravelのセキュリティ対策 — 本番ハードニング実務リファレンス
Laravelの既定は堅いが、本番事故は設定・運用から起きる。本ページは実務リファレンス。(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)危険な既定設定の一覧表 (3)領域別の具体対策＝秘密/APP_KEY・本番設定(APP_DEBUG/キャッシュ)・認可(Policy/Gate・Mass Assignment)・インジェクション/出力(Eloquentバインド・Blade)・セッション/CSRF/Cookie・アップロード・HTTPS/ヘッダ/レート制限・依存(Composer)CVE (4)自己検証チェック。攻撃手順は扱わず、防御と点検に限定。
Next.jsのセキュリティ対策 — 本番ハードニング実務リファレンス
Next.jsの既定は安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝境界と環境変数(NEXT_PUBLIC_)・依存CVE(本体RCE含む)・Server Actions/Route Handlersの認可＋入力検証・SSRF(サーバー側fetch)・セキュリティヘッダ/CSP・認証/セッション/Cookie・レート制限 (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Spring Bootのセキュリティ対策 — 本番ハードニング実務リファレンス
Spring Bootは堅い基盤だが、事故は依存・設定・認可から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝依存CVE(Log4Shell系・実稼働版で判定)・本番設定と秘密の外部化・Spring Securityの認可(既定拒否/メソッド認可/所有者チェック)・Actuator/管理面の露出削減・安全でないデシリアライズ・インジェクション・ヘッダ/CSRF/セッション・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
WordPressのセキュリティ対策 — 本番ハードニング実務リファレンス
WordPressは世界最大シェア＝最大の標的だが、事故の入口はほぼ決まっている（プラグイン/テーマの脆弱性・放置更新・弱い管理者・露出した管理画面）。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝更新の自動化・プラグイン/テーマ最小化・強い管理者＋2FA・管理画面の露出削減(xmlrpc/REST列挙/ファイル編集)・wp-configと秘密・ファイル権限・HTTPS/バックアップ・PHP/依存の鮮度 (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
ASP.NET Coreのセキュリティ対策 — 本番ハードニング実務リファレンス
ASP.NET Coreは成熟した堅い基盤だが、事故は設定から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝本番で詳細エラー/開発者例外ページを露出しない・秘密の外部化(User Secrets/環境/Key Vault)・NuGet依存CVE・認可([Authorize]・フォールバックで既定拒否・リソースベース/所有者)・over-posting(DTO/[Bind])・安全でないデシリアライズ(BinaryFormatter回避)・HTTPS/ヘッダ/antiforgery・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Express（Node.js）のセキュリティ対策 — 本番ハードニング実務リファレンス
Expressは最小主義＝既定でほぼ守らない。守りは開発者が自分で足す。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝セキュリティヘッダ(helmet)＋x-powered-by無効化・依存(npm)CVE・入力検証とインジェクション(SQL/NoSQL演算子)・認証と所有者スコープの認可・レート制限とサイズ上限・セッション/Cookie/CSRF・SSRF・本番のエラー処理(スタック非露出)・NODE_ENV (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Ruby on Railsのセキュリティ対策 — 本番ハードニング実務リファレンス
Railsは規約と安全な既定(CSRF保護・Strong Parameters・ORM)を備えるが、本番事故は運用から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝秘密とcredentials(master key/secret_key_base)・本番設定(force_ssl・例外非露出)・gem CVE・Strong Parameters/Mass Assignment・認可(Pundit等・所有者スコープ)・インジェクションと危険メソッド(where連結/send/constantize)・セッション/Cookie/CSRF・SSRF/アップロード (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。