「攻撃者が用意したIDで、被害者がログインしてしまう」——それがセッション固定です。仕組みと、確実な防ぎ方を解説します（攻撃手順は載せません）。
なぜ成立するか（仕組み）
鍵は「ログイン前後でセッションIDが変わらない」設計にあります。変わらなければ、ログイン前に攻撃者が知っていたIDが、ログイン後も“認証済み”として通用してしまいます。
CSRF や XSS と組み合わされることもありますが、セッション固定そのものの本質は「ログイン時にIDを作り直していない」という一点です。
防御：ログイン時にIDを作り直す
ログイン成功時にセッションIDを再生成（最重要）
URL経由のセッションID指定を受け付けない
Cookie属性を固める
HttpOnly（JSから読めない）・Secure（HTTPSのみ）・SameSite（別サイト起点の送信を抑制）を付ける。関連する乗っ取り経路をまとめて弱める。適切な失効を設ける
当サイトの視点：フレームワークの『再生成』を外さない
セッション固定は、自前の凝った対策ではなく「ログイン時にIDを再生成する」一手でほぼ封じられます。重要なのは、フレームワークが用意しているこの仕組みをうっかり外さない・呼び忘れないこと。独自のセッション管理を自作するより、実績のある実装の既定動作に乗るのが安全です。当サイトは「認証や鍵まわりは自作しない・既定の安全側を外さない」を原則にしています。IDOR と同様、認証・認可まわりは“仕組みで毎回効かせる”のが肝です。
次に読む
よくある質問
Qセッション固定とセッション乗っ取りは何が違う？
セッション乗っ取り（hijacking）は、すでに発行された他人のセッションIDを“盗む”攻撃です。セッション固定（fixation）は逆で、攻撃者が“自分の知っているID”を先に被害者へ使わせ、被害者がそのIDでログインするのを待つ攻撃です。盗むのではなく、最初から知っているIDを認証済みにさせるのが特徴です。
Q一番の防御は？
『ログインの瞬間にセッションIDを再生成する』ことです。多くのフレームワークやセッションライブラリにこの機能（session regenerate / renew）があり、認証が成立した時点で古いIDを捨てて新しいIDを発行します。これだけで、攻撃者が事前に仕込んだIDは無効になります。権限が上がる操作（管理者昇格など）でも再生成します。
QURLにセッションIDを入れるのはなぜ危険？
URLにIDが乗ると、リンク共有・リファラ・ログ・ブラウザ履歴を通じて第三者に渡りやすく、攻撃者が“固定したいID”を被害者に踏ませる入口になります。セッションIDはURLパラメータではなくCookieで扱い、URL経由のID指定は受け付けないのが安全です。