Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#39806 closed enhancement (wontfix)

Disable REST API by default, making it opt-in rather than always-on

Reported by: mor10's profile mor10 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.8
Component: REST API Keywords: close
Focuses: Cc:

Description

Disable the REST API by default and enable it only when the site admin requests it or a theme or plugin is dependent on it for full functionality.

For sites that do not take advantage of the REST API, its always-on status is not beneficial. Its sole function in this scenario is for 3rd parties to gain access to content. This should be an active decision made by the site owner/admin, not a global decision made by the application.

I propose three changes to address this issue:

  1. REST API is disabled by default and site admin is given the option to enable it during initial install and later via a toggle on the Settings view. Admin should be allowed to toggle the REST API status at any time, akin to how search engine crawling is controlled.
  2. A define( ‘WP_REST_API’, false ); option is introduced in wp-config.php to globally enable/disable REST API.
  3. Theme and plugin authors can declare REST API dependency in their setup. When the theme/plugin is activated, the site admin is notified this requires the REST API to be enabled allowing transparency and handing the decision to the admin.

With these three enhancements, the REST API will be available for those who want to use it, rely on it, and/or want to open their content to consumption from 3rd parties while keeping it disabled for those who do not want to use it or, maybe most importantly, are not aware what this feature is and have no use for it.

Change History (21)

#1 follow-up: @ocean90
7 years ago

and enable it only when the site admin requests it or a theme or plugin is dependent on it for full functionality.

And what about core itself? #39634, #39553, #38922, #38343, #38342, #38920 or #34207, to name just a few.

#2 follow-up: @SergeyBiryukov
7 years ago

The current plan is to introduce more core functionality that relies on REST API.

As noted in #38446, turning off the REST API is like turning off admin-ajax.php — both will break your site.

#3 in reply to: ↑ 1 @mor10
7 years ago

Replying to ocean90:

and enable it only when the site admin requests it or a theme or plugin is dependent on it for full functionality.

And what about core itself? #39634, #39553, #38922, #38343, #38342, #38920 or #34207, to name just a few.

From the looks of it, these are mostly admin features, no? If so would it be feasible to enable the REST API only on admin?

For clarity, I know eventually WP will use the REST API heavily at which point it should be enabled by default. However, at this moment in time it is still in its infancy and recent events show it still has room to mature. Therefore it seems only reasonable to limit its availability to only cases where it is actually in use, and allow site owners/admins to make an active decision to disable the feature if they do not want or need it. Treat it as what it is: progressive enhancement.

I'm not working against progress here, I just want to leave control of such a powerful feature in the hands of the site owners. I've seen many compelling reasons for disabling the feature, very few for leaving it always-on.

#4 in reply to: ↑ 2 ; follow-up: @mor10
7 years ago

Replying to SergeyBiryukov:

The current plan is to introduce more core functionality that relies on REST API.

As noted in #38446, turning off the REST API is like turning off admin-ajax.php — both will break your site.

IMO that's an argument to tie REST API availability to user roles or public/private demarcation line.

#5 in reply to: ↑ 4 ; follow-up: @jnylen0
7 years ago

  • Keywords close added

Replying to mor10:

IMO that's an argument to tie REST API availability to user roles or public/private demarcation line.

If you really want to disable the REST API on your site(s), this is our current recommendation: restrict it to authenticated users. However, we want to continue to increase adoption and usage of the REST API, and I expect that even this modification will break more and more WP functionality as time goes on, such as API-driven themes and embeds.

Still, here is one example of a plugin that follows this recommendation for WP 4.7+: https://wordpress.org/plugins/disable-json-api/

There used to be a rest_enabled filter, however, we deprecated it in WP 4.7 when the endpoints shipped. As previously noted, lots more discussion on #38446 where this change happened.

This ticket can be closed as wontfix, IMO.

#6 follow-up: @lukecavanagh
7 years ago

@mor10

Another plugin which adds that option to disable, as well as removing endpoints is.

https://wordpress.org/plugins/rest-api-toolbox/

#7 in reply to: ↑ 6 ; follow-up: @jnylen0
7 years ago

Replying to lukecavanagh:

Another plugin which adds that option to disable, as well as removing endpoints is https://wordpress.org/plugins/rest-api-toolbox/

This plugin appears to be at least partially broken: https://plugins.trac.wordpress.org/browser/rest-api-toolbox/trunk/includes/class-rest-api-toolbox-common.php?rev=1574456&marks=113#L106

Under normal (unauthenticated) usage, $error will be null, so the code to restrict the API will never run.

#8 in reply to: ↑ 7 ; follow-up: @GunGeekATX
7 years ago

Replying to jnylen0:

Replying to lukecavanagh:

Another plugin which adds that option to disable, as well as removing endpoints is https://wordpress.org/plugins/rest-api-toolbox/

This plugin appears to be at least partially broken: https://plugins.trac.wordpress.org/browser/rest-api-toolbox/trunk/includes/class-rest-api-toolbox-common.php?rev=1574456&marks=113#L106

Under normal (unauthenticated) usage, $error will be null, so the code to restrict the API will never run.

Thanks, I'll take a look at that. It appears to be working, http://baconmockup.com/wp-json and the various wp/v2 endpoints all show that the API is disabled, but I see that core is passing null, so I'll add some updates to check for this.

#9 in reply to: ↑ 8 ; follow-up: @jnylen0
7 years ago

Replying to GunGeekATX:

Thanks, I'll take a look at that.

I take that back - it does work, and here's why:

Still, I wouldn't recommend this approach.

#10 in reply to: ↑ 9 @GunGeekATX
7 years ago

Replying to jnylen0:

Replying to GunGeekATX:

Thanks, I'll take a look at that.

I take that back - it does work, and here's why:

Still, I wouldn't recommend this approach.

Disabling the REST API, or the code around $error? I do agree that I should have better checking for WP_Error, nulls, etc.

#11 @jnylen0
7 years ago

I wouldn't recommend disabling the REST API, for reasons already noted in this ticket.

#12 follow-up: @helen
7 years ago

Why should this be treated differently from XML-RPC? Have you gone through the history of the XML-RPC setting?

#13 in reply to: ↑ 5 @mor10
7 years ago

Replying to jnylen0:

However, we want to continue to increase adoption and usage of the REST API, and I expect that even this modification will break more and more WP functionality as time goes on, such as API-driven themes and embeds.

As I stated in the proposal, plugins and themes would declare REST API dependency.

#14 in reply to: ↑ 12 @mor10
7 years ago

Replying to helen:

Why should this be treated differently from XML-RPC? Have you gone through the history of the XML-RPC setting?

The main concern voiced by people seems to be a) inbound data, and b) ease of use. Similar to XML-RPC, but with additional concerns added.

This ticket was created in part to ask a recurring question not fully addressed about why the REST API is always-on by default. I'm not invested in disabling the feature myself, but enough conversations are happening that it needs to be addressed in a more public way. Making the case, as is being done in these responses, will quell at least some of these concerns.

#15 @knutsp
7 years ago

Its sole function in this scenario is for 3rd parties to gain access to content.

The sole function of WordPress is to gain access to content! (read for the public, write for the authenticated users)

  • Web "API" for browsers/humans
  • Feeds for applications (read only)
  • XMLRPC and REST APIs for applications, including WordPress core, themes and plugins
  • admin-ajax for core

If REST API becomes default disabled then development of core, themes and plugins that want to use this latest and greatest of APIs will halt. Who wants to explain users why and how to enable it, without indicating this is something extraordinary that opens some dangerous gate?

If themes and plugins should "opt-in" or "require" the REST API, how should that happen? Should those override the site admin's decision not to enable it? Or just notify and pray? Well, ok, and the grant the same option to core, and core will "require" REST API very soon.

Either the REST API is immature and should not be part of core (but that train has left, really), or it should be always on, until someone who knows what it is disables it by a plugin or some simple code.

The discussions around REST API and it's inclusion in core has been long. One of the last criteria for accepting it in was the benefits for core itself and the use by core.

That's where we are.

#16 @pcarvalho
7 years ago

I believe REST API has a place within wp, and hopefully be useful in improving rewrites.

With that said,
what we have done, at server level, was to block and ban ips requesting wp-json in our servers.

It has been a though week.

Lastly, I'm puzzled why this endpoint isn't protected by default:

Why make it easier than ever to get all the usernames?

thanks for reading,
p.

#17 @spidoche
7 years ago

I think it's must be disable by default too (at least on the front),

My client site has been hack via the REST api only 4days after the 4.7 vulnerability was revealed,
It's seem nowadays hackers do not let's us time to update our wordpress TT.

Also the example of @pcarvalho surprise me , how it is possible to get the user data without authentication?

Version 0, edited 7 years ago by spidoche (next)

This ticket was mentioned in Slack in #core-restapi by jnylen. View the logs.


7 years ago

#19 @lukecavanagh
7 years ago

Could is_user_logged_in() not be used, so the WP REST API is only enabled by default if a user if logged in.

#20 @joehoyle
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

@lukecavanagh you could do that, also a think a good idea that I haven't seen implemented yet is to only allow access to the REST API using the nonce, therefore you could (somewhat) lock down access to the API for requests from the site, logged in, or out. However I should point out that this isn't all that secure, due to the length that nonces live for.

Either way, I think all these things are plugin territory, and the default for the REST API is _on_. The more WP functionality core functionality we see moving to be build on the REST API, the more it will become not possible to disable it. The REST API is not just an external facing layer on WordPress, it is core functionality.

As per usual, if you don't want your site to be publicly accessible, there are plugins and other means of doing that - but it's not a default / feature of WordPress core to enable such a thing.

I know this ticket is somewhat controversial, so my closing of it may ruffle some feathers. In the interest of keeping track clean, and wrapping up the discussion here, I'm closing this as wontfix.

This ticket was mentioned in Slack in #core-restapi by spidoche. View the logs.


6 years ago

Note: See TracTickets for help on using tickets.