Cookie authentication is vulnerable to Cross-Site Request Forgeries (CSRF). WordPress handles this problem by using nonces (number used once). Learn how nonces work and why they are necessary when using the WordPress REST API within the context of WordPress.
- [Voiceover] Cookie authentication has some inherent security flaws that have been resolved in WordPress Core. If we use the REST API within the context of WordPress, most of these issues are handled for us automatically, but in the case of cross-site request forgeries, we have to mimic the behavior of WordPress Core in our own code for things to work properly. First things first, what are cross-site request forgeries? Consider this: when we use a verb on a route in the REST API, we are, in effect, just sending a URL with a bunch of associated data to the server.
So, for example, if I want to delete the post with the ID 32, all I'm really doing is this: I pass the verb delete to the route, restful.dev/wp-json/wp/v2/posts/32. If you're not an authenticated user, this would not work no matter what because you don't have the correct privileges to delete a post, but if you are an authenticated user and you are logged in, this command will land the post in the trash bin.
That sounds fine, right? Well, there's a sinister problem lurking under this simplicity. With no other protections in place, it would be technically possible to send this request to the server from a different site. Someone with less than noble intentions could create a small script attached to a button on any site, then have someone logged in to their WordPress site click on that button and use the authenticated cookie setting in the browser to add, change, or delete content in the site. That would be incredibly dangerous so it's not possible, thanks to what's known as the nonce or number used once.
In WordPress, it works like this. When the user logs into WordPress, the application generates a unique nonce for that session. The nonce isn't really a number, but a hash made from numbers and letters. The nonce stays alive for one day, after which, a new nonce is generated automatically. When the user performs an action in WordPress admin, the nonce is passed along with that action in the URL. You can actually see the nonce in action when you're logged in to the back-end of WordPress. Here I'm in the post editor and when I hover over the move to trash link, you'll see at the bottom in my browser you have the URL to the move to trash function, and at the very end it says, WP nonce equals, and then an encrypted key.
When the action is performed, WordPress checks the nonce to make sure it matches its records. If the nonce is correct, the action takes place. If the nonce is incorrect or missing altogether, you get an error. Nonces make it almost impossible to generate requests from outside of WordPress. They are a crude but effective measure for preventing outside forces from messing with your site. So we have two layers of protection here. First, the server uses the cookie to check if the browser is who it claims to be and that the current user has the authority to do what they want to do.
Second, WordPress uses the nonce to make sure WordPress itself generated the request that is being passed in. If the nonce doesn't exist or the nonce is wrong, it means the request is coming from somewhere else so nothing will happen. When we use the REST API within the context of WordPress, cookie authentication is already handled by the browser and the server, so all we have to do is bring the nonce along for the ride to get things done.
- What is authentication and when do you need it?
- Cookie authentication
- Creating a plugin for front-end editing
- Adding the front-end editing functionality using jQuery
- Limiting front-end editing to authorized users
- What is JWT authentication?
- Adding editing capability using Ajax
- OAuth 2 authentication
- Configuring JSO
- Making login and log out states meaningful