依存管理
このタグの記事 4 件
Express（Node.js）のセキュリティ対策 — 本番ハードニング実務リファレンス
Expressは最小主義＝既定でほぼ守らない。守りは開発者が自分で足す。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝セキュリティヘッダ(helmet)＋x-powered-by無効化・依存(npm)CVE・入力検証とインジェクション(SQL/NoSQL演算子)・認証と所有者スコープの認可・レート制限とサイズ上限・セッション/Cookie/CSRF・SSRF・本番のエラー処理(スタック非露出)・NODE_ENV (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Next.jsのセキュリティ対策 — 本番ハードニング実務リファレンス
Next.jsの既定は安全寄りだが、事故は『サーバーとクライアントの境界』で起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝境界と環境変数(NEXT_PUBLIC_)・依存CVE(本体RCE含む)・Server Actions/Route Handlersの認可＋入力検証・SSRF(サーバー側fetch)・セキュリティヘッダ/CSP・認証/セッション/Cookie・レート制限 (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)自己検証チェック。攻撃手順は扱わず防御と点検に限定。
Spring Bootのセキュリティ対策 — 本番ハードニング実務リファレンス
Spring Bootは堅い基盤だが、事故は依存・設定・認可から起きる。本ページは実務リファレンス：(1)優先度つきハードニング・チェックリスト(P0〜P2) (2)領域別の具体対策＝依存CVE(Log4Shell系・実稼働版で判定)・本番設定と秘密の外部化・Spring Securityの認可(既定拒否/メソッド認可/所有者チェック)・Actuator/管理面の露出削減・安全でないデシリアライズ・インジェクション・ヘッダ/CSRF/セッション・SSRF (3)自己検証チェック。攻撃手順は扱わず防御と点検に限定。