タグアーカイブ 認証

REST APIに非ログイン状態でアクセスできなくなった時の原因と解決手順

プラグインや本体のアップデートを機に、外部サービスからのREST APIリクエストが「Only authenticated users can access the REST API.」というエラーで拒否されるようになった場合、多くのケースではプラグインの認証設定が更新によって変更されている。まずは該当プラグインの「REST APIアクセスを許可する」設定を見直し、それでも改善しなければバージョン固有の不具合を疑う。

なぜアップデート後にREST APIが突然使えなくなるのか

WordPressのREST APIは、外部アプリやサービスとサイトがデータをやり取りするための共通の窓口だ。決済ゲートウェイの通知（ウェブフック）、モバイルアプリからの記事取得、別サーバーとの在庫連携など、多様な自動処理がREST APIを通じて動いている。

プラグインのバージョンアップでアクセスが遮断される原因は、大きく分けて二つある。ひとつはセキュリティ強化を目的とした仕様変更で、非ログインユーザー（未認証リクエスト）に対する制限が新たに追加、あるいは既定で有効化されたケースだ。もうひとつは、アップデート時のコードの不具合で「REST APIを許可する」設定が内部的に無視されてしまうケースである。

いずれの場合も、ウェブフックを受け取るサイト側では「ログインしていない外部からのPOSTリクエスト」として扱われるため、認証エラーが返ってしまう。ECサイトの決済通知や予約システムの在庫更新など、リアルタイム性が求められる連携ほど被害が大きい。

プラグイン設定でREST APIのアクセス制御を確認する

最初に行うべきは、該当プラグインの設定画面にREST API関連の項目が存在するかどうかの確認だ。多くのセキュリティ系プラグインやユーザー管理プラグインには「REST APIへのアクセスを制限する」「未認証ユーザーをブロックする」といったチェックボックスが用意されている。

管理画面から該当プラグインの設定ページを開き、「REST API」「APIアクセス」「外部リクエスト」「認証」などのキーワードを含む項目を探す。もし「未認証ユーザーのREST APIアクセスを無効にする」といった設定がオンになっていれば、これをオフに切り替えて保存し、外部からのリクエストが再び通るかをテストする。

設定項目の名称や位置はプラグインによって異なる。セキュリティタブの中にあったり、詳細設定の一番下に隠れていたりすることも多い。見つからない場合はプラグインのドキュメントや公式サポートフォーラムで「REST API permission」をキーに検索する。

プラグインのバージョンを切り戻して検証する

設定が正しく「許可」になっているにもかかわらずAPIが機能しない場合、プラグイン自体の不具合を疑う段階に入る。管理画面上は許可しているように見えて、内部的な処理では設定値を正しく読み取れていない可能性がある。

まずは該当プラグインの安定していた旧バージョンを入手し、手動でインストールし直す。公式プラグインディレクトリの「以前のバージョン」セクションや、プラグイン開発者がGitHubでリリースしているアーカイブからダウンロードできる。

切り戻しは次の手順で進める。プラグイン一覧画面で問題のプラグインを一度無効化し、削除する（設定データは残るため心配は不要）。続いて旧バージョンのZIPファイルを「プラグイン」→「新規追加」→「プラグインのアップロード」からインストールし有効化する。この状態で外部からのAPIリクエストが正常に処理されるかテストし、復旧を確認したら開発元に不具合報告を送る。

どうしても旧バージョンが入手できない場合は、WP Rollbackプラグインを使って管理画面から直接ダウングレードする方法もある。ただし本番サイトでの使用は慎重に行い、必ず事前にバックアップを取得しておく。

特定エンドポイントだけを許可するカスタム対応

セキュリティ上の理由からREST API全体を無制限に開放したくない場合は、必要なエンドポイントだけを選択的に許可する方法が有効だ。たとえば決済ゲートウェイのウェブフックは特定のルート（/wp-json/wc/v3/ordersなど）だけ通ればよい。

テーマのfunctions.phpに以下のようなフィルターを追加すれば、特定のRESTルートに対して認証要件を緩和できる。コードを直接書く場合は必ず子テーマを利用する。

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }
    if ( strpos( $_SERVER['REQUEST_URI'], '/wp-json/my-plugin/v1/webhook' ) !== false ) {
        return true;
    }
    return $result;
});

このコードは、指定したパス（上の例では/my-plugin/v1/webhook）へのアクセスに対して認証チェックをスキップし、それ以外のエンドポイントは通常の認証を維持する。プラグイン本体を修正せずに済むため、アップデートが来ても上書きされる心配がない。

フィルターを追加した後は必ず、許可したエンドポイントに外部からcurlコマンドやPostmanでテストリクエストを送り、意図したとおりに動作することを確認する。想定外のエンドポイントが開放されていないかも併せてチェックする。

リバースプロキシやWAFがリクエストを遮断していないか調べる

プラグインの設定もバージョンも問題ないのにAPIが機能しない場合、サーバー環境側でリクエストが遮断されている可能性がある。CDNのWAF（ウェブアプリケーションファイアウォール）、ホスティング側のセキュリティモジュール、あるいは.htaccessの記述が原因で、外部からのPOSTリクエストがブロックされているケースは意外に多い。

確認すべきはログだ。WAFを導入している場合はその管理画面で遮断ログを検索し、APIリクエストが誤検知でブロックされていないか調べる。サーバーのアクセスログでは、対象のエンドポイントにリクエストが到達しているかどうか、到達している場合のHTTPステータスコード（401や403なら認証・権限の問題、200系ならアプリケーション側で正常処理後にエラーが発生している）をチェックする。

とくに管理画面のURLを変更するプラグインや、xmlrpc.phpを無効化する設定が、間接的にREST APIのエンドポイントにまで影響を与えていることもある。これらの設定も一時的に解除してテストを行う。

よくある質問

どのプラグインがREST APIに影響を与えているか特定するには

全プラグインを一度無効化し、問題のエンドポイントに外部からアクセスして正常応答を確認する。その後、プラグインを1つずつ有効化しながら再テストすれば、原因のプラグインを絞り込める。テーマのfunctions.phpのカスタムコードも疑わしい場合は、標準テーマに一時的に切り替えて検証する。

外部サービスが受け取るエラーの内容を詳しく知るには

WordPressのREST APIは認証エラー時にJSON形式のエラーオブジェクトを返す。外部サービス側でHTTPレスポンスボディをログに残せるなら、codeとmessageの値を取得すれば原因の手がかりになる。ログが取れない場合は、curlで手動リクエストを送り、curl -vでレスポンスボディを直接確認する。

REST API全体を無効化せずにセキュリティを保つ方法はあるか

特定のIPアドレスからのみアクセスを許可する.htaccessの設定、APIキーやアプリケーションパスワードを使った認証の義務付け、あるいは必要なエンドポイントだけをホワイトリスト登録するカスタムコードで対応できる。無制限の全面開放は避け、必要最小限の権限に絞ることが安全面でも推奨される。

プラグインをダウングレードしても問題はないのか

セキュリティ修正や脆弱性対策を含むアップデートを巻き戻すことになるため、ダウングレードはあくまで一時的な回避策と位置づける。復旧を確認したら速やかに開発元へ報告し、修正バージョンがリリースされたらすぐに更新する。ダウングレード期間中はサイト全体の監視を強化する。

アップデート前のバージョンが不明な場合はどうするか

プラグイン一覧画面の「詳細を表示」から「開発」タブを開くと、過去のバージョン履歴が参照できる。または公式プラグインディレクトリの「Advanced View」に「Previous Version」のリンクが用意されている。どうしてもわからない場合は、バックアップから前回正常に動作していたプラグインファイルを復元する。

この記事のポイント

• プラグイン更新後にREST APIが遮断されたら、まず設定画面のアクセス制御項目を確認する
• 設定が正しくても動かない場合は、旧バージョンに切り戻して不具合を検証する
• 必要なエンドポイントだけをfunctions.phpのフィルターで選択的に開放できる
• WAFやサーバー設定がリクエストをブロックしていないかログで確認する
• ダウングレードは一時的な対策とし、修正版のリリースを待って更新する

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている