WordPress安心診断 by MozCheck

WordPressのREST APIを安全に無効化・制限する方法｜セキュリティ向上と特定ルート制限

Written by

Yudai Tsuyuzaki

in

「WordPressのREST APIからユーザー名が誰でも見られると聞いて不安になった」「REST APIを完全に無効化したら、管理画面で記事が保存できなくなって焦った」「セキュリティを高めつつ、ブロックエディタやプラグインを壊さない正しい制限方法が知りたい」――WordPressのサイト運営や開発において、このような疑問やトラブルに直面していませんか？

WordPress 4.7以降、標準機能としてコアに統合された **「WordPress REST API（WP REST API）」** は、外部アプリケーションとの連携やヘッドレスCMS化、さらには標準のブロックエディタ（Gutenberg）の通信基盤として不可欠な技術です。しかしその一方で、初期設定では認証なしでインターネット全体に広く公開されており、エンドポイント（ /wp-json/wp/v2/users ）を叩くだけで管理者や投稿者のログインIDが丸見えになってしまうという重大なセキュリティリスクを抱えています。

ここで多くのWeb制作者や管理者が陥りがちなのが、 **「危険ならREST APIを丸ごと完全停止（全面無効化）してしまおう」** という安易な対応です。古い解説記事で見かける全面無効化コードを適用した結果、 **「更新に失敗しました。返答が正しいJSONレスポンスではありません」** というエラーでブロックエディタが動かなくなったり、サイトヘルス機能が警告を出したり、お問い合わせフォームの非同期送信が動かなくなるといった大事故が頻発しています。

本記事では、WordPress専門のセキュリティ診断メディアである当サイトの知見をもとに、 **「REST APIを完全無効化してはいけない技術的理由」** を明快に解説した上で、サイトの利便性を1ミリも損なわずにセキュリティを高める **「3大ベストプラクティス（未ログイン制限・特定ルートピンポイント無効化・ホワイトリスト制御）」** のコピペ動作コード、おすすめプラグイン設定、curlコマンドによる動作検証手順までを徹底的に完全ガイドします。

目次

【無料診断】あなたのWordPressサイトのREST APIは安全ですか？

「自社サイトのユーザー一覧エンドポイントが外部から見えているか分からない」「セキュリティ設定が正しく効いているか確認したい」という方は、Webセキュリティ診断ツール **「MozCheck（モズチェック）」** をご活用ください。URLを入力するだけで、REST APIの露出状況やログイン画面の脆弱性を約1分で無料自動チェックできます。

MozCheckで無料セキュリティ診断を試す →

WordPressのREST APIとは？デフォルトで公開されているセキュリティリスク

まずは、WordPress REST APIがそもそも何のために存在し、なぜデフォルトで外部に公開されているのか、そして放置するとどのような脅威が生じるのかを整理しましょう。

REST APIの基本概要とWordPress標準で有効化されている理由

WordPress REST API（WP REST API）とは、HTTPリクエストを通じてWordPressのデータ（投稿、固定ページ、カテゴリ、タグ、ユーザー情報、メディアなど）をJSON形式でやり取りするための汎用インターフェースです。URLの末尾に /wp-json/ を付与してリクエストを送ることで、ブラウザや外部プログラムからサイト内のデータを取得・操作できます。

WordPressがバージョン4.7でREST APIを標準機能としてコアに統合した最大の理由は、 **「WordPressのオープンWebプラットフォーム化」** と **「管理画面の近代化」** です。従来のWordPressはPHPがサーバーサイドでHTMLをレンダリングするモノリシックな仕組みでしたが、REST APIの搭載により以下のような高度な活用が可能になりました。

  • ヘッドレスCMS運用の実現： フロントエンドにNext.js、Nuxt、Astro、React、Vueなどを採用し、バックエンドのコンテンツ管理機能のみをWordPressに委託するアーキテクチャ。
  • スマートデバイス・外部アプリ連携： スマートフォンアプリや社内基幹システム、IoTデバイスから投稿データの取得や更新を自動化。
  • Gutenberg（ブロックエディタ）の動作基盤： WordPress 5.0で導入されたブロックエディタは、JavaScript（Reactベース）で動作しており、投稿の自動保存、ブロックパターンの取得、メタデータの更新など、あらゆる通信をREST API経由で行っています。

このように、REST APIは現代のWordPressにとって心臓部とも呼べる通信インフラです。そのため、WordPressをインストールした初期状態では、 **誰でも認証なしで読み取り系エンドポイントにアクセスできるオープンな仕様** に設計されています。しかし、このオープンさこそがセキュリティ上の大きな落とし穴となっています。

最大のリスク：/wp-json/wp/v2/users による管理者ユーザー名（ログインID）の露出

WordPress REST APIにおける最大のセキュリティ懸念は、 **「ユーザー一覧エンドポイント（ /wp-json/wp/v2/users ）」がデフォルトでゲスト（未認証の第三者）に公開されていること** です。

試しに、ご自身のサイトURLの後ろに /wp-json/wp/v2/users を付けてブラウザで開いてみてください。特別な対策をしていない場合、以下のようなJSONレスポンスがそのまま返ってくるはずです。

[
  {
    "id": 1,
    "name": "SiteAdmin",
    "url": "",
    "description": "",
    "link": "https://example.com/author/siteadmin/",
    "slug": "siteadmin",
    "avatar_urls": { ... }
  },
  {
    "id": 2,
    "name": "Taro Yamada",
    "url": "",
    "description": "",
    "link": "https://example.com/author/editor_yamada/",
    "slug": "editor_yamada",
    "avatar_urls": { ... }
  }
]

ここで注目すべきは、 **slug（スラッグ）フィールド** です。WordPressでは、管理者のログインID（ユーザー名）が初期設定でそのまま著者スラッグとして利用されることが多く、攻撃者はこのJSONを見るだけで **「ログイン画面に入力すべき正確なユーザー名（ログインID）」を労せずして100%特定** できてしまいます。

WordPressへの不正アクセス攻撃（ブルートフォース攻撃やパスワードリスト攻撃）は、 **「ユーザー名」** と **「パスワード」** の2つの鍵を揃えるゲームです。REST APIによってユーザー名が筒抜けになっている状態は、攻撃者に対して **「鍵穴の半分を無償でプレゼントしている」** のと同義であり、パスワードの総当たり突破を極めて容易にしてしまいます。

※ユーザー名の露出対策については、別記事 WordPressのユーザー名（ログインID）を隠す完全ガイド でも詳しく解説していますが、REST APIエンドポイントの遮断はその中でも最優先の防御策となります。

悪意あるボットによる過度なAPIリクエスト（DoS攻撃・コンテンツスクレイピング）のリスク

ユーザー名漏洩に加えて警戒すべきリスクが、 **悪意ある海外ボットやクローラーによる過度なAPIリクエスト** です。

  • サーバー負荷増大とDoS（サービス不能）リスク： REST APIのエンドポイント（ /wp-json/wp/v2/posts 等）は、データベースに対して複雑なクエリ（JOINやソート、メタ情報の展開）を実行します。通常のHTMLページのようにキャッシュプラグインのフルページキャッシュが効きにくいケースが多く、ボットが毎秒数十〜数百回のリクエストを送りつけると、MySQLサーバーのCPU使用率が100%に達し、サイト全体がダウン（503 Service Unavailableやデータベース接続確立エラー）してしまいます。
  • コンテンツの機械的スクレイピング（無断転載）： REST APIを介せば、HTMLのパース（解析）を一切行わずに、記事本文・タイトル・アイキャッチ画像URL・カスタムフィールドの純粋なテキストデータをJSON形式で高速かつ一括取得できます。コピーサイトやスパムサイト運営者にとって、これ以上ない好都合な「データ吸い出し口」となってしまうのです。
  • サイト内部構造の偵察・情報収集： インストールされているプラグインやテーマがREST APIルートを登録している場合、APIインデックス（ /wp-json/ ）を走査するだけで、導入済みプラグインの種類やバージョン情報、未公開の下書きタイトルなどが推測される危険性があります。

【要注意】REST APIを「完全無効化」してはいけない3つの理由

上記のセキュリティリスクを知ると、「それなら rest_api_init をすべて無効化するか、rest_enabled フィルターで丸ごとAPIを止めよう」と考える方が非常に多くいらっしゃいます。インターネット上の古いブログ記事（WordPress 4.9以前の時代に書かれた記事）の中には、今でもそのような全面停止コードを紹介しているものが散見されます。

しかし、 **現代のWordPressにおいてREST APIを完全に無効化することは「サイトの破壊行為」に等しく、絶対にやってはいけません** 。その決定的な3つの理由を解説します。

1. Gutenberg（ブロックエディタ）が正常に動作しなくなる（「更新に失敗しました」エラー）

最も致命的な副作用が、 **管理画面のブロックエディタ（Gutenberg）が完全に動作不能になること** です。

ブロックエディタは、記事の新規作成・編集画面を開いた瞬間から、裏側でREST API（ /wp-json/wp/v2/posts や /wp-json/wp/v2/types 等）と常時非同期通信を行っています。記事の下書き自動保存、カテゴリーの新規追加、タグの選択、アイキャッチ画像の設定、公開・更新ボタンの押下など、 **エディタ上のあらゆる操作がREST APIを通じて実行** されます。

もしREST APIを完全無効化してしまうと、エディタは以下のような致命的なエラーを吐き出し、記事の執筆や保存が一切できなくなります。

  • 「更新に失敗しました。 返答が正しい JSON レスポンスではありません。」
  • 「公開に失敗しました。 エラーメッセージ: 予期しないトークン < です。」
  • 記事の自動保存が失敗し、執筆中のデータが消失する
  • ブロックの追加や再利用可能ブロック（同期パターン）の展開が無限ローディングになる

「クラシックエディタ（Classic Editorプラグイン）を使っているから大丈夫」と思われるかもしれませんが、クラシックエディタであっても後述するサイトヘルスや各種プラグインで障害が発生するため、やはり全面停止は推奨されません。

2. サイトヘルス機能、ブロックパターン、ウィジェットの読み込みが破損する

WordPress 5.2以降、管理画面の「ツール」→「サイトヘルス」機能が標準搭載されています。サイトヘルスは、サーバー環境のセキュリティやパフォーマンスを監視する重要機能ですが、この診断ロジック自体が内部的にREST APIへの自己疎通テストを行っています。

REST APIを完全無効化すると、サイトヘルスのダッシュボードに **「REST APIでエラーが発生しました」「ループバックリクエストが完了しませんでした」** という重大な致命的エラー（Critical Issue）が常時表示されるようになります。

さらに、WordPress 5.8以降の「ブロックウィジェット画面（外観 → ウィジェット）」や「ブロックテーマ（フルサイト編集 / FSE）」、公式ディレクトリからブロックパターンを検索・挿入する機能もすべてREST APIに依存しているため、管理画面の主要機能が次々と崩壊してしまいます。

3. 外部連携プラグイン（Jetpack、Contact Form 7、SEOプラグイン等）やスマホアプリとの同期が遮断される

多くの主要プラグインも、フロントエンドや管理画面での動作にREST APIを活用しています。

プラグイン / ツール REST APIへの依存内容と完全無効化時の不具合
Contact Form 7 REST API経由での非同期送信（Ajax）が遮断され、フォーム送信時にローディングが止まらない、またはページリロードを伴うフォールバック動作になる
Yoast SEO / All in One SEO エディタ内でのリアルタイムSEO解析・読みやすさスコアの計算、ソーシャルメタデータのプレビュー取得が失敗する
Jetpack WordPress.comサーバーとのクラウド同期、アクセス統計データの集計、自動バックアップ機能が完全に切断される
WordPress公式モバイルアプリ スマートフォンやiPadのWordPress公式アプリからブログにログインできず、記事投稿・画像アップロードが全滅する
WooCommerce ECサイトのカート・決済通信、在庫管理、外部受注連携システムとのAPI連携がストップする

以上のように、REST APIを全停止することは、 **「自らサイトの機能を破壊して不具合を量産する行為」** にほかなりません。目指すべきゴールは全面停止ではなく、 **「必要な機能（エディタや信頼できる通信）を生かしつつ、不要な外部露出のみを安全に遮断する」** ことです。

【ベストプラクティス】REST APIを安全に制限する3つの実装手法

それでは、サイトを壊さずにセキュリティを高めるための **「安全な制限手法（ベストプラクティス）」** を解説します。運用の目的やサイトの性質に応じて、以下の3つの手法から最適なものを選択してください。

制限アプローチ ブロックエディタへの影響 ユーザー名隠蔽 おすすめ対象サイト
手法1: 未ログイン制限
（rest_authentication_errors）		 影響なし
（管理画面ログイン中は正常動作）		 完全遮断
（外部からは401返却）		 外部に公開APIを提供していない通常のコーポレートサイト・ブログ（最も推奨）
手法2: /wp/v2/users ピンポイント非公開
（rest_endpoints）		 影響なし
（他のAPI機能は全て維持）		 完全遮断
（404 Not Found返却）		 公開API（記事一覧の外部配信など）を提供しつつ、ユーザー名流出だけ防ぎたいサイト
手法3: ホワイトリスト制御
（許可ルートのみ開放）		 設計次第
（コア必須ルートの許可が必要）		 完全遮断 ヘッドレスCMSや特定エンドポイントのみを厳格に社外連携させたい高度なWebアプリケーション

手法1: 未ログインユーザー（ゲスト）のみREST APIアクセスを禁止するコード（rest_authentication_errors フック）

WordPressにおいて最も安全で実績があり、公式にも推奨されているアプローチが、 **「ログインしていないユーザー（未認証の外部アクセス）に対してのみ、REST APIの利用に認証を要求する（401 Unauthorizedを返す）」** という実装です。

この手法を採用すると、 **管理画面にログインしている管理者・編集者は普段どおりブロックエディタやサイトヘルスを何の問題もなく利用** できます。一方で、外部の悪意あるボットや未認証ユーザーが /wp-json/ 以下のエンドポイントにアクセスしようとすると、HTTP 401エラーで即座に門前払いされます。

子テーマの functions.php または自作のサイト専用プラグイン（Must-Useプラグイン推奨）に、以下のコードを追記してください。

<?php
/**
 * 未ログインユーザーに対するREST APIアクセスを安全に制限する
 * ログイン済みユーザー（管理者・編集者等）はブロックエディタを含め正常に動作します
 */
add_filter('rest_authentication_errors', function($result) {
    // 既に他の認証処理でエラー（または成功）が確定している場合はそのまま返す
    if (!empty($result)) {
        return $result;
    }

    // ユーザーがログインしていない場合のみ、認証エラー（HTTP 401）を返却してアクセスを遮断
    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            __('You are not currently logged in.'),
            ['status' => 401]
        );
    }

    return $result;
});

【コードのポイント解説】：

  • rest_authentication_errors フィルターフックの利用： WordPressコアがREST APIリクエストをディスパッチ（処理）する直前に実行される標準フックです。ここで WP_Error オブジェクトを返すと、コアはエンドポイントの処理を中断し、指定されたステータスコード（401）で安全に終了します。
  • if (!empty($result)) の判定： 他の認証プラグイン（JWT、OAuth、アプリケーションパスワードなど）が先行してエラーを返している場合、その結果を上書きせずに尊重するための安全設計です。
  • ブロックエディタとの完全な親和性： ブロックエディタを開いている管理者は既にWordPressにCookieログインしているため、is_user_logged_in() は true となり、一切通信が阻害されません。「更新に失敗しました」エラーとは無縁です。

手法2: /wp/v2/users（ユーザー情報）のみをピンポイントで無効化・404化するコード（rest_endpoints フック）

「サイトの最新記事一覧を外部の別サイトや静的ジェネレーターに配信したいので、未ログインユーザーへのREST API全遮断（手法1）はできない。しかし、ユーザー名（ログインID）が漏れる /wp/v2/users だけはどうしても塞ぎたい」というケースも多いでしょう。

そのような場合は、 **rest_endpoints フィルターフック** を使い、登録されているエンドポイント一覧から「ユーザー一覧」と「個別ユーザー詳細」のルートだけをピンポイントで削除（unset）します。これにより、攻撃者がアクセスしても **「404 Not Found（存在しないページ）」** となり、ユーザー情報が外部から完全に隠蔽されます。

<?php
/**
 * /wp/v2/users エンドポイントのみをピンポイントで非公開（404化）にする
 * 記事データ等の公開REST APIは維持しつつ、ユーザー名漏洩のみを確実に防止します
 */
add_filter('rest_endpoints', function($endpoints) {
    // ユーザー一覧エンドポイント（/wp-json/wp/v2/users）を削除
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }

    // 個別ユーザー情報エンドポイント（/wp-json/wp/v2/users/1 等）を削除
    if (isset($endpoints['/wp/v2/users/(?P<id>[d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[d]+)']);
    }

    return $endpoints;
});

【コードのポイント解説】：

  • 不要なルートを完全登録解除： rest_endpoints フックは、登録されているすべてのRESTルート配列を保持しています。ここで配列からキーを unset することで、WordPressはそのルートを「そもそも定義されていない」と判断し、安全に404エラーを返します。
  • 正規表現パターンの指定： 個別ユーザーのエンドポイントは正規表現 /wp/v2/users/(?P<id>[d]+) で登録されているため、この正規表現キーを正確に指定して削除することが重要です。
  • 管理画面への影響なし： 管理画面のユーザー一覧画面は管理画面用PHP（wp-admin/users.php）で処理されるため、このフックでRESTルートを削除しても管理業務に一切支障はありません。

手法3: 独自カスタムAPIルートのみを許可し、コアエンドポイントを保護するホワイトリスト設計

自社で開発した特定のカスタムエンドポイント（例: /my-custom-plugin/v1/data ）や、お問い合わせフォーム専用の通信ルートのみを外部公開し、それ以外のコアエンドポイント（記事、ページ、ユーザー、タクソノミー等）をすべて一括遮断したい場合は、 **「ホワイトリスト方式（許可リスト）」** の設計が極めて有効です。

<?php
/**
 * 指定したプレフィックスのカスタムAPIのみ許可し、
 * 未ログイン時のWordPressコアAPI（/wp/v2/）を一括保護するホワイトリスト設計
 */
add_filter('rest_authentication_errors', function($result) {
    if (!empty($result)) {
        return $result;
    }

    // ログイン済みユーザーは無条件で許可（管理画面・ブロックエディタの保護）
    if (is_user_logged_in()) {
        return $result;
    }

    // 現在リクエストされているURIを取得
    $current_uri = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '';

    // 外部公開を許可するエンドポイントのプレフィックス（ホワイトリスト）
    $allowed_prefixes = [
        '/wp-json/contact-form-7/',       // Contact Form 7 の非同期送信
        '/wp-json/my-app/v1/',             // 自作の独自カスタムAPI
    ];

    // リクエストURIが許可プレフィックスに含まれているか判定
    foreach ($allowed_prefixes as $prefix) {
        if (strpos($current_uri, $prefix) !== false) {
            return $result; // 許可されたAPIはそのまま通過
        }
    }

    // ホワイトリストにない未認証アクセスは一律 401 Unauthorized
    return new WP_Error(
        'rest_access_restricted',
        __('Access to this API endpoint requires authentication.'),
        ['status' => 401]
    );
});

このホワイトリスト設計を活用すれば、「Contact Form 7のお問い合わせ送信は誰でも使えるように残したいが、WordPressコアのユーザー情報や記事データは一切外部から見せたくない」といった実務でよくある高度なセキュリティ要件をスマートに満たすことができます。

プラグインを使って手軽にREST APIを制限・制御する方法

「functions.php にコードを追記するのは記述ミスやテーマ更新で上書きされるのが怖い」「GUIの管理画面からワンクリックで手軽にREST APIを制限したい」という場合は、信頼性の高い専用プラグインを活用するのがおすすめです。

プラグイン1: 「Disable WP REST API」（設定不要で未ログインユーザーのみ一括制限）

最もシンプルかつ軽量でおすすめなのが、 **「Disable WP REST API」** （開発者: Dave McHale）です。

  • プラグインの特徴： プラグイン名に「Disable」と付いていますが、実際にはREST APIを全停止するのではなく、 **「未ログインユーザーに対してのみHTTP 401を返し、ログイン中ユーザーにはREST APIを完全開放する」** という、先ほどの手法1（rest_authentication_errors）と全く同一の安全なロジックが組み込まれています。
  • 導入手順：
    1. 管理画面の「プラグイン」→「新規追加」を開く。
    2. 検索窓に「Disable WP REST API」と入力して検索。
    3. 「今すぐインストール」をクリックし、そのまま「有効化」をクリック。
  • 設定の要不要： 特別な設定画面は一切ありません。 **有効化するだけで即座に未ログインユーザーに対するREST APIが遮断** されます。ブロックエディタはそのまま快適に利用可能です。

プラグイン2: 「All-In-One Security (AIOS)」や「XO Security」でのREST API制御機能

すでに総合セキュリティプラグインを導入している場合や、ログインセキュリティと一元管理したい場合は、プラグイン内のREST API制御機能をONにするだけで対応できます。

1. All-In-One Security (AIOS) での設定手順：

  • 管理画面左メニュー「WP Security」→「その他（Miscellaneous）」を開く。
  • 「WP REST API」タブを選択。
  • **「ログインしていないユーザーの REST API へのアクセスを禁止する（Disallow unauthorized REST requests）」** にチェックを入れる。
  • 「設定を保存」をクリック。

※AIOSも未ログインユーザーのみを遮断するため、ブロックエディタが壊れる心配はありません。

2. XO Security（国産セキュリティプラグイン）での設定手順：

  • 管理画面「設定」→「XO Security」を開く。
  • 「REST API」タブを選択。
  • **「REST APIを無効化する」** の項目で、「未ログインユーザーのみ無効化」を選択する（「すべてのユーザー」を選ばないよう注意）。
  • ユーザーエンドポイントのみを隠したい場合は、 **「/wp/v2/users を無効化する」** にチェックを入れるだけでピンポイント制限が可能。

※セキュリティプラグインの詳しい比較や選び方については、別記事 WordPressセキュリティプラグインおすすめ比較 もあわせてご参照ください。

REST API制限後の動作検証と安全確認チェックリスト

コードの記述やプラグインの有効化が終わったら、必ず以下の3つのステップで **「外部からは遮断され、内部業務は正常に稼働しているか」** の動作検証を行いましょう。

ブラウザやcurlコマンドでエンドポイント（/wp-json/wp/v2/users）へアクセス検証

まずは外部（未ログイン状態）からのアクセスが正しく遮断されているかを確認します。ブラウザのシークレットウィンドウ（プライベートブラウズ）を開くか、ターミナルから curl コマンドを実行してテストします。

# 未ログイン状態でのユーザーエンドポイント検証（HTTPレスポンスヘッダーを確認）
curl -i https://your-site.com/wp-json/wp/v2/users

【確認すべきレスポンスステータス】：

  • 手法1（未ログイン制限）の場合：
    レスポンスヘッダーに HTTP/1.1 401 Unauthorized が返り、ボディに {"code":"rest_not_logged_in","message":"You are not currently logged in."} というJSONが返ってくれば制限成功です。
  • 手法2（ピンポイント非公開）の場合：
    レスポンスヘッダーに HTTP/1.1 404 Not Found が返り、{"code":"rest_no_route","message":"No route was found matching the URL and request method."} が返れば成功です。記事一覧（ /wp-json/wp/v2/posts ）は 200 OK で正常取得できることも併せて確認してください。

管理画面でブロックエディタの保存・公開が正常に行えるかの確認

次に、管理画面にログインした状態でブロックエディタの挙動を確認します。

  • テスト記事の新規作成： 管理画面から「投稿」→「新規追加」を開く。
  • コンテンツ入力と自動保存： 見出しや段落ブロックを入力し、右上の「下書き保存」をクリック。数秒待って「下書き保存済み」と表示されるか確認。
  • 「更新に失敗しました」エラーが出ないこと： 「公開」ボタンを押して即座に公開ステータスになることを確認。
  • ブラウザの開発者ツール（F12）確認： コンソール（Console）タブおよびネットワーク（Network）タブを開き、赤文字のREST APIエラー（401や500）が多発していないかチェック。

お問い合わせフォームのAjax送信や外部連携が正常に動作するか確認

最後に、サイト訪問者が利用するフロントエンド機能の動作確認を行います。

  • お問い合わせフォーム（Contact Form 7等）： シークレットウィンドウで実際にお問い合わせページを開き、テスト送信を実行。送信完了メッセージ（緑色の枠）が正常に表示されるか確認。
  • 検索機能・ページネーション： サイト内検索やAjaxを用いた「もっと見る」ボタンが正常に機能しているか確認。
  • 外部連携ツールの疎通： Google Search Consoleやアナリティクス、Jetpack等の連携ツールで同期エラーの警告が出ていないか確認。

まとめ：サイトの利便性を損なわずにREST APIを守る

WordPressのREST APIは、現代のWeb制作やエディタ環境において欠かせない強力な基盤です。しかし、標準のまま無防備に放置しておくと、管理者ユーザー名（ログインID）が簡単に特定され、不正アクセスの温床となってしまいます。

本記事で解説した重要なポイントを振り返りましょう。

  • 全面停止は厳禁： REST APIを完全無効化すると、ブロックエディタの保存エラー、サイトヘルスの異常、プラグイン破損を引き起こす。
  • 最も推奨される対策： rest_authentication_errors フックまたは「Disable WP REST API」プラグインを使い、 **「未ログインユーザーのみ401で弾く」** アプローチを採用する。
  • 公開APIが必要な場合： rest_endpoints フックを使い、 **/wp/v2/users だけをピンポイントで404化** してユーザー名漏洩を防ぐ。
  • 実装後の検証： curl コマンドでの401/404レスポンス確認と、管理画面でのブロックエディタ保存テストを必ず実施する。

REST APIを安全に制限することは、WordPressセキュリティを強固にするための極めて効果的な第一歩です。さらに、ログイン画面への **2段階認証（2FA）の導入** や **XML-RPCの停止** を組み合わせることで、サイトの防御力は劇的に向上します。

あわせて読みたい関連記事

セキュリティ対策後の総点検に！MozCheckの無料診断

REST APIの制限設定が完了したら、外部からのアクセスが本当に防げているか、他の箇所に脆弱性が残っていないかを **「MozCheck（モズチェック）」** で確認してみましょう。ログインIDの露出やSSL設定、主要なセキュリティヘッダーの適用状況をわずか1分で客観的に判定します。

今すぐMozCheckでサイト診断を行う（無料） →

関連記事

  1. セキュリティ、後回しにしていませんか？あなたのWordPressを守る対策
  2. WordPressセキュリティ対策 完全ガイド｜初心者から中小企業まで守る実践チェックリスト
  3. WordPressの403 Forbiddenエラー原因と直し方完全ガイド｜管理画面・記事保存時のWAF解除から.htaccess・パーミッション復旧まで
  4. WordPressに2段階認証（2FA）を設定する方法｜おすすめプラグイン比較と締め出し防止策

投稿者

Yudai Tsuyuzaki

フリーランスのWeb系プログラマー。 長野県の北アルプス地方在住

🧰 WordPress無料診断

サイト改善の第一歩をお届け

当サイト「MozCheck」は、WordPressサイトの不安をチェックできる無料診断サービスです。
URLを入力するだけ。登録不要、すぐに診断結果が表示されます。

無料で診断する

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

More posts