WP REST API Post Status Using JavaScript

Question

I am getting my hands dirty in WP REST API. I have gone through a couple of tutorials and have a question using JavaScript to create a new post.

In this tutorial, the post var status = 'draft'; (see code). So I am just worried that won't anyone able to hack that status?

jQuery( document ).ready( function ( $ ) {
    $( '#post-submission-form' ).on( 'submit', function(e) {
        e.preventDefault();
        var title = $( '#post-submission-title' ).val();
        var excerpt = $( '#post-submission-excerpt' ).val();
        var content = $( '#post-submission-content' ).val();
        var status = 'draft'; // this code

        var data = {
            title: title,
            excerpt: excerpt,
            content: content
        };

        $.ajax({
            method: "POST",
            url: POST_SUBMITTER.root + 'wp/v2/posts',
            data: data,
            beforeSend: function ( xhr ) {
                xhr.setRequestHeader( 'X-WP-Nonce', POST_SUBMITTER.nonce );
            },
            success : function( response ) {
                console.log( response );
                alert( POST_SUBMITTER.success );
            },
            fail : function( response ) {
                console.log( response );
                alert( POST_SUBMITTER.failure );
            }

        });

    });

} );

Answer 1

In this tutorial, the post var status = 'draft'; (see code). So I am just worried that won't anyone able to hack that status?

It depends who it is. A logged out user cannot create any posts at all. A subscriber cannot either. A contributor could create the post, but not publish it. An author or editor role however can change it to publish.

---

So, lets say that the user is logged in, and has a role that lets them publish posts, and they are on that page, and you're concerned that they might change status = "draft" to status = "publish".

First, the bug in your code

Firstly, the status variable is never used due to a bug in your code. The posts get created as draft posts not because you said so, but because that's the default status.

To fix this bug, you need to add this to data:

status: status

Until you do that, they could change status to "banana" and it wouldn't do anything.

Second, REST is stateless

The REST API doesn't know what page the user is on, that's not how REST API's work. What they can and can't do is controlled via capabilities.

So who cares if they can modify your variable when they can just poke the API themselves?

They could copy paste the following code into their browsers dev tools console:

$.ajax({
        method: "POST",
        url: POST_SUBMITTER.root + 'wp/v2/posts',
        data: {
            title: "hello world",
            content: "post content",
            status: "publish"
        },
        beforeSend: function ( xhr ) {
            xhr.setRequestHeader( 'X-WP-Nonce', POST_SUBMITTER.nonce );
        },
    });

And hey presto, they don't need to modify your code! They have their own. As I said earlier, REST API requires 3 things:

• a nonce
• a cookie
• the required capabilities to do what's being asked.

Nothing requires them to use the code from your theme, or for your code to even load. As long as they're logged in, and they have the capability, it will allow them.

Who Can Change a Posts Status in The REST API?

Which is the crux of your question, and the answer is it depends. Anybody who tells you either yes or no is a liar, and has not thought it through.

For example, a contributor cannot publish a post, so if they changed the post_status to publish the API would reject the request. You'd receive a JSON structure telling you that what you tried was forbidden, and a 403 forbidden HTTP response code.

If a subscriber user tried, it would reject it too, even if the status was draft, because subscribers cannot create posts. You'd receive a JSON structure telling you that what you tried was forbidden, and a 403 forbidden HTTP response code.

If an administrator tried it, it would work, because administrator roles can do anything. You'd get a 200 http code success response. The same of an editor of author, because those roles can do that, as demonstrated by them being able to go to wp-admin and click the publish button.

This is because those roles have the capability to publish posts assigned to their roles. If you removed that capability then they would no longer be able to publish in the REST API, or the WP Admin interface

So as you see, It depends on the roles and capabilities of the logged in user making the request