WordPress CMS is used by many blogging websites, agency websites, e-commerce and sometimes organizational data such as employees or students or even patients / clients. People are likely to have no idea of data exposure via API Endpoint and are likely to have some level of security policy that does not require names to be publicly listed. I think this is an issue and it should be an opt-in.

The JSON REST API for WordPress can be useful for developers using WordPress to build apps. But it may be unusable for general people or website owners–and it may potentially expose the website to DDoS attacks that may be resource-intensive, slowing down the website.

Sometimes, General Users and Event Developers underestimate the amount of data provided by the endpoint of the WordPress REST API. Everything is open to anyone or anything that asks: articles, sites, groups, tags, comments, taxonomies, media, users, settings, etc.

For instance, if you have a JSON-powered news reader, it can reproduce virtually anywhere your entire site structure. But that easy access calls for potential abuse. Just as with RSS feeds, JSON content is easily scrapped and used for spam, phishing, plagiarism, adsense, and other foul things.

In addition to content theft and plagiarism, these endpoints act as gateway to another possible security and privacy over user data. By design, WordPress provides substantial amounts of user data to anyone or anything that asks. For any user (of any role) who is the author of at least one post, literally everyone has access to their personal information. What user data is presented through the REST API?

As explained in the report, all but user email addresses and passwords are provided by the/users endpoint. Everything else— ID, Name, Website, Definition, URL, Metadata and more — thanks to the REST API, all the public domain.

To give you a more concrete example of the data shared publicly through the REST API, consider the following URL: https:/ashokkuikel.com/wp-json/wp/v2/users/9 Here we invoke the REST API by calling a particular endpoint for the user (i.e., user ID=9). Requesting the URL in a browser to return the following data:

{
	"id": 3,
	"name": "Ashok Kuikel",
	"url": "http:\/\/ashokkuikel.rejq6qmdqz-58e60rro56d7.p.runcloud.link",
	"description": "Ashok Kuikel is a Professional Web Application Developer and a Cloud Architect",
	"link": "http:\/\/ashokkuikel.rejq6qmdqz-58e60rro56d7.p.runcloud.link\/author\/ashokkuikel\/",
	"slug": "ashokkuikel",
	"avatar_urls": {
		"24":"https:\/\/secure.gravatar.com\/avatar\/...",
		"48":"https:\/\/secure.gravatar.com\/avatar\/...",
		"96":"https:\/\/secure.gravatar.com\/avatar\/..."
	},
	"meta": [],
	"_links": {
		"self":       [{"href":"http:\/\/ashokkuikel.rejq6qmdqz-58e60rro56d7.p.runcloud.link\/wp-json\/wp\/v2\/users\/9"}],
		"collection": [{"href":"http:\/\/ashokkuikel.rejq6qmdqz-58e60rro56d7.p.runcloud.link\/wp-json\/wp\/v2\/users"}]
	}
},

This same information also is available at other endpoints, for example:

https://ashokkuikel.com/wp-json/wp/v2/users

What’s the Risk?

The main risks are basically the same for everything except the user data as for RSS feeds. Scrapers and theft of content are knowledgeable enough to steal your content irrespective of format. If you make stealing your content easy for people, they’ll. So whether the data is being grabbed via RSS or JSON format, content is content, and the REST API makes it easier for anyone and anything to manipulate the content, categories, tags, meta, and much more of your site. Is it acceptable? Your decision entirely.

We are now reaching an entirely new level of danger for user data. The information is confidential with user data, so there is a potential risk to privacy. Even worse, their default “Name” is their “Show Name” for each user, which defaults to the registered username unless specified otherwise. It means that the registered user names of your website are available to the public, so there is a potential security risk.

Security Risk

For the security risk, the significance and extent of the issue is up for debate^1,2,3. In general, bad actors require at least two things to gain access to your site:

1. Username
2. Password

And they now have half of what they need thanks to the WP REST API. The REST API thus presents a weakness to protection by making it easier for attackers to brute-force their way to your site. Rather than having to guess the right username AND password, they just have to guess the password now. Which is just too ridiculously easy to do for many user accounts.

How to Secure the REST API

• If you are developer and you need the rest endpoint then you can modify the rest Endpoint prefix.
  • Without Plugin

    add_filter( 'rest_url_prefix', 'modify_endpoint_api_slug'); 
     function modify_endpoint_api_slug( $slug ) {
       return 'custom_endpoint'; 
     }
    flush_rewrite_rules(true);
    

• if you wants to disable it completely.
  • Without Plugin

    add_filter('json_enabled', '__return_false');
    add_filter('json_jsonp_enabled', '__return_false');
    
    Optional
    
    add_filter( 'rest_authentication_errors', 'wp_snippet_disable_rest_api' );
    function wp_snippet_disable_rest_api( $access ) {
    return new WP_Error( 'rest_disabled', __('The WordPress REST API has been disabled.'), array( 'status' => rest_authorization_required_code()));
    }
    add_filter( 'rest_authentication_errors', 'wp_snippet_disable_rest_api' );
    function wp_snippet_disable_rest_api( $access ) {
    return new WP_Error( 'rest_disabled', __('The WordPress REST API has been disabled.'), array( 'status' => rest_authorization_required_code()));
    }

Through returning an instance of WP Error when it enters the authentication process, the following code snippet will disable the WordPress REST API.

Instructions:
All you need to do is add this code to the functions.php file of your theme or to a plugin unique to your domain.
* Test the site to work as intended after the WordPress JSON REST API has been disabled.