Why is the REST API enabled by default?
-
Hello, I have a website, but I am sure it is not only my website, hundreds, thousands of websites have their REST API exposed (though read-only). After enabling pretty permalinks all the REST API is exposed and enabled on website.com/wp-json.
Almost any website has the API exposed and visiting/wp-json/wp/v2/usershelps me find easily which users are registered. This should be considered a security issue, not because of the technical difficulties, but because a lot (if not the whole) of the information from the website is exposed.
Maybe there is a wordpress ticket about this, but I was not able to find it.
-
WordPress uses the REST API itself, so it needs to be enabled for things like the new editor. Plugins can modify the user listing issue — install WordFence. for example:
See https://i.imgur.com/zJRIBy4.png
@katsar0v Don’t create duplicate topics. I’ve closed your other topic.
tl;dr You can disable that via a plugin. I use this one.
https://ww.wp.xz.cn/plugins/disable-wp-rest-api/
For added security add a 2FA plugin.
https://ww.wp.xz.cn/plugins/search/2FA/
I personally use this one.
https://ww.wp.xz.cn/plugins/two-factor/
Longer reply:
There is nothing exposed by
/wp-json/wp/v2/usersthat is not already exposed viahttps://some-site-url/author/userid/and user name enumeration has never been about security. Nor will it ever be, the public portion of the login transaction is assumed to be well, public.For example: My user names are these.
jdembowskiWhich you can get herehttps://profiles.ww.wp.xz.cn/jdembowski/And here
https://ww.wp.xz.cn/support/users/jdembowski/And here
https://make.ww.wp.xz.cn/support/author/jdembowski/And even on my own site here
https://blog.dembowski.net/author/jan/asjanwhich doesn’t work because I broke my site in a little way. The links are on each of my 900+ blog posts there though.And on Twitter too
https://twitter.com/jan_dembowski/asjan_dembowskiI can also log into any of those systems using my email address which I will not publish ’cause spam. It’s not really a secret though and no, do not post anyone’s email here to make a point.
All of my systems use passwords like this.
2XbM*aTA9qtgV!HUy_LC@c mDjAt323viF@pW3dZbtN!a PhYPvPPEjkb3qu*x@ZykEaI use a tool called 1Password to generate those though there are many others. When I’m feeling particularly security conscious I enable 2FA for the logins.
Anything that you cannot explicitly control such as your user ID cannot be considered part of a security solution. That’s why you have passwords and in many places 2FA or even MFA (which is cool). Your user ID like your email address is just an identifier. It’s never meant to be secret and in the case of your email address, you hand it out all the time.
You didn’t write the below quote but I’m trying to be complete.
But you use a plugin to disable REST API for non-logged in users.
Yes, but not for security. I’m trying and failing to filter Gravatars in REST API responses. I installed that plugin to see how it works.
(Gravatars potentially expose email addresses and I substitute them for an inline base64 encoded image. I don’t think it’s a threat either but I had an afternoon free.)
If you make the user ID secret, you now have two secrets. And if your secret user ID is out there what recourse do you have? Get a new user ID? You can change your password as often as you like. That was it’s designed purpose and that’s where security is addressed.
Use strong passwords. Add 2FA if you feel it is necessary. But don’t place security in your user ID. That’s not it’s intended purpose anywhere.
Thank you for the detailed reply. Is there a specific reason why this rest API is not adjustable by the WordPress Core (here I mean the default installation and settings page)?
It has already happened several times that the core “consumed” some plugins in itself, so the functionality already exists when you install WordPress. I understand your point of view and you are correct about the urls (though mostly this is up to the theme whether authors and comments are shown and etc.)
here is nothing exposed by /wp-json/wp/v2/users that is not already exposed via https://some-site-url/author/userid/ and user name enumeration has never been about security
I would kind of disagree here, I am not trying to be technical, but rather look from a blogger / simple user perspective. Technically what
/author/:iddelivers id fully dependant from the theme. There are several fields of information (as well meta information) and the theme decides what to show – the use case is that you look for a theme, see the demo and see that there is an author page and what (as well how) is shown there. In the meantime whether you want it or not, the wordpress rest api just shows the information. Ok, you install the plugin, but wouldn’t it be better if those settings weren’t default (defensive strategy?)?The usernames shouldn’t be considered a security issue – you are correct again. But imagine you register on a wordpress website which has no
/author/:idurl. You cannot write articles, you registered because of the “premium” service (just a use case, one of the many that probably exist). Now this website does show article author information, however because you registered your account is exposed to/wp-json/wp/v2/users. I am repeating myself probably again here, but I just wanted to say this should be viewed as a privacy issue as well, not only security.(Gravatars potentially expose email addresses and I substitute them for an inline base64 encoded image. I don’t think it’s a threat either but I had an afternoon free.)
The emails are exposed as well and this is again more a privacy then a security issue. A wordpress website cannot guarantee that the emails stay private if/wp-json/wp/v2/usersbasically exposes the md5 of your email. The MD5 hashing algorithm was once considered secure cryptographic hash, but those days are long gone. But this is too technical and I’d not bother for now (but a potential issue as well)The real-world use case with the obama foundation – the theme does not show any author information,
/author/:nameis not accessible, but the rest api lets you basically know who is the editorial team behind this.The funny thing though (I am not sure, but it is most probably true) is that the rest api respects the feed limitation from the settings page (which is by default 10). Also may not be a big issue, but the
/wp-jsonendpoint reveals all endpoints also registered from other plugins and this exposes basically which plugin is installed on the website.Is there a way to escalate this into a “feature request” or discuss this topic with core developers? 5.3 or 5.4 version could easily include a minimal setting, that makes even a non-technical blogger aware, that information is exposed there. A switch could be also easily made, whether this to be private or not. It really should be not the case to install plugins for basic stuff, which should be done by the cms (my own opinion)
PS: I created a trac ticket – https://core.trac.ww.wp.xz.cn/ticket/48043#ticket
Would be happy if someone else also shares his oppinion
How does that refute anything I’ve written? In any sense or form? Honest question.
It was just an example how the rest api might expose data the owner might not want to have public. The obama foundation itself is a showcase wordpress shows proudly, so that’s why I took it, but surely there are thousands of websites having the same issue.
There is no privacy issue here either, just some behavior that you may find undesirable. Which leads to the suggestion to write some code or use a plugin. I myself prefer a plugin but the actions and filters are not difficult to work with.
I don’t think this is just me, but if you think so, okay. There are exploiters and scripts automatically looking for wordpress vulnerability and
/wp-jsonis like a golden mine now for them, because they can now easily find out which plugins are installed that use the rest api.I raised a trac ticket with feature request, as already said, am happy to read also some other opinions 🙂
@sterndata if headless is the reason, I saw absolute 0 talks in wordcamps across europe about it. Haven’t seen the docs mention headless (though i haven’t read them all).
- The topic ‘Why is the REST API enabled by default?’ is closed to new replies.