2026年9月17日

WordPressのCookieベースのセッション管理を強化するセキュリティ設定

ログイン・アクセス

WordPress のログイン状態は、サーバー側のセッションではなく「認証 Cookie」と、ユーザーメタに保存されるセッショントークンの組み合わせで管理されています。強化の要点は、HTTPS で Cookie を守る、ログインの有効期間を役割に合わせて短くする、不要なセッションを消せるようにする、の3つです。この記事では仕組みを確認したうえで、wp-config.php とフィルターでできる設定を順に説明します。

WordPress の認証 Cookie の仕組み

ログインすると、WordPress はおおむね次の Cookie を発行します（名前の末尾にはサイトごとのハッシュが付きます）。

wordpress_sec_…（HTTPS の場合）または wordpress_…：管理画面やプラグインの領域で使う認証 Cookie
wordpress_logged_in_…：サイト全体で「ログイン中」を判定する Cookie

Cookie の中身はユーザー名、有効期限、セッショントークン、そして wp-config.php の認証用キーとソルトから計算した署名です。署名があるので Cookie を書き換えて別人になることはできませんが、Cookie そのものを盗まれると、有効期限まではそのユーザーとして扱われます。対策の中心が「盗まれにくくする」「盗まれても使える時間を短くする」「使えなくできるようにする」になるのはこのためです。

セッショントークンはユーザーメタ（session_tokens）に保存されており、トークンを消せば対応する Cookie は無効になります。プロフィール画面にある「他のすべての場所からログアウト」に相当するボタンは、この仕組みを使っています（表記はバージョンで変わることがあります）。

なお、WordPress の認証 Cookie には HttpOnly 属性が付いており、JavaScript から読み出せません。それでもクロスサイトスクリプティング（XSS）があれば、Cookie を読まなくてもログイン中の権限で操作されてしまいます。Cookie の設定と並行して、プラグインやテーマを更新し、入力のサニタイズと出力のエスケープを徹底することが前提です。

設定1：HTTPS を前提にし、Secure 属性付きで発行する

サイト全体を HTTPS にしたうえで、wp-config.php に次を書きます。作業前に wp-config.php のバックアップを取ってください。

// 管理画面とログインを HTTPS に限定する
define( 'FORCE_SSL_ADMIN', true );

WordPress は HTTPS でアクセスされていると判断したときに、Secure 属性付きの認証 Cookie を発行します。リバースプロキシや CDN の背後にあるサーバーでは、WordPress から見ると HTTP で届いているため、HTTPS と判定されないことがあります。その場合はプロキシが付ける X-Forwarded-Proto を見て $_SERVER['HTTPS'] を設定するのが一般的ですが、このヘッダーは信頼できるプロキシ経由のときだけ使ってください。直接アクセスできるサーバーで無条件に信用すると、偽のヘッダーで判定をすり抜けられます。

確認は、ブラウザの開発者ツールでログイン後の Cookie を開き、wordpress_sec_… と wordpress_logged_in_… に Secure と HttpOnly が付いているかを見ます。

さらに HSTS ヘッダーを使うと、ブラウザが HTTP で接続しなくなり、Cookie が平文で流れる余地を減らせます。HSTS は一度設定すると取り消しに時間がかかるため、最初は短い max-age で試してください。

設定2：ログインの有効期間を短くする

既定では、ログイン状態の保持期間は「ログイン状態を保存する」なしで2日、ありで14日です。管理者が共用 PC や持ち出し端末で14日間ログインしたままになるのは避けたいところです。期間は auth_cookie_expiration フィルターで変えられます。

<?php
/**
 * Plugin Name: Session Hardening
 * 管理者権限を持つユーザーだけ、ログインの有効期間を短くする。
 * wp-content/mu-plugins/session-hardening.php に置く。
 */
add_filter( 'auth_cookie_expiration', function ( $length, $user_id, $remember ) {
	if ( user_can( $user_id, 'manage_options' ) ) {
		// 「ログイン状態を保存する」あり: 2日 / なし: 8時間
		return $remember ? 2 * DAY_IN_SECONDS : 8 * HOUR_IN_SECONDS;
	}
	return $length; // それ以外のユーザーは既定のまま
}, 10, 3 );

テーマの functions.php ではなく mu-plugin に置くと、テーマを切り替えても設定が外れません。変更は次回ログインから効きます。既にログインしている端末の期限は変わらないので、すぐに反映したい場合は後述の方法で既存セッションを切ってください。

会員サイトなどで一般ユーザーの期間を極端に短くすると、ログインし直しが増えて使い勝手が落ちます。権限が強いユーザーほど短く、という考え方で調整するのが現実的です。

設定3：同時ログインを制限する

1人のアカウントが複数の端末で同時に使われていると、そのうちの1台から Cookie が漏れても気付きにくくなります。ログインのたびに、ほかの端末のセッションを切る例です。

<?php
/**
 * ログインに成功したら、その時点のセッション以外を破棄する（管理者のみ）。
 * set_logged_in_cookie の6番目の引数が新しいセッショントークン。
 */
add_action( 'set_logged_in_cookie', function ( $cookie, $expire, $expiration, $user_id, $scheme, $token ) {
	if ( ! user_can( $user_id, 'manage_options' ) ) {
		return;
	}
	$manager = WP_Session_Tokens::get_instance( $user_id );
	$manager->destroy_others( $token );
}, 10, 6 );

この設定を入れると、別の端末でログインした時点で古い端末はログアウトされます。複数端末で作業する管理者がいる場合は事前に周知してください。

設定4：既存のセッションをまとめて無効にする

不正ログインの疑いがあるとき、退職者のアカウントを止めるとき、テーマやプラグインの脆弱性を修正した直後などは、既存の Cookie を無効にします。

特定ユーザーだけ：そのユーザーのプロフィール画面から全端末をログアウトさせるか、パスワードを変更します。コードからなら WP_Session_Tokens::get_instance( $user_id )->destroy_all(); で同じことができます
全ユーザー：wp-config.php の認証用キーとソルト（AUTH_KEY など8つ）を新しい値に替えます。署名の前提が変わるため、すべての認証 Cookie が無効になります

WP-CLI が使える環境では、キーとソルトの入れ替えを1行で実行できます。

# 実行前に wp-config.php をバックアップする。実行後は全員ログインし直しになる
cp wp-config.php wp-config.php.bak
wp config shuffle-salts

キーを手で替える場合は、WordPress.org の秘密鍵生成サービスで発行した値を使い、ネット上の記事に載っている値をコピーしないでください。

設定5：ログイン試行の制限と PHP セッションの設定

Cookie を盗むより、パスワードを総当たりするほうが攻撃としては手軽です。ログイン試行回数の制限（Limit Login Attempts Reloaded や Wordfence などのプラグイン、またはサーバー側の WAF）と二要素認証を組み合わせてください。設定を誤って自分が締め出された場合に備え、FTP でプラグインのフォルダ名を変えて無効化する手順を確認しておきます。

WordPress のコアは PHP のセッション（session_start()）を使いませんが、プラグインが使っていることがあります。その場合は php.ini などで次の設定を確認します（設定できる場所はサーバーによって異なります）。

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"
session.use_strict_mode = 1

認証 Cookie の SameSite 属性については、WordPress のコアは明示的に付けていません（2026年10月現在）。主要ブラウザは属性がない Cookie を Lax 相当として扱いますが、扱いはブラウザによって異なります。サーバー設定で Set-Cookie ヘッダーを書き換えて付与する方法もありますが、外部サービスからのリダイレクトを伴うログイン（SSO や決済）が壊れることがあるため、ステージングで十分に確かめてから適用してください。

まとめ

WordPress のログイン状態は、署名付きの認証 Cookie とユーザーメタのセッショントークンで管理されている
FORCE_SSL_ADMIN と HTTPS で Secure 属性付きの Cookie を発行し、開発者ツールで属性を確認する
auth_cookie_expiration で、権限の強いユーザーほどログインの有効期間を短くする
必要なら set_logged_in_cookie と WP_Session_Tokens で同時ログインを制限する
緊急時はセッションの破棄や認証用キーとソルトの入れ替えで既存 Cookie を無効にする
ログイン試行の制限と二要素認証を併用し、設定変更は mu-plugin とステージングで行う