• I have many WordPress sites connected to Wordfence Central and all work fine. I want to disable the WordPress REST API to unauthenticated requests as an enhanced security measure.

    To achieve this I use the following code:

    add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) {
    return $result;
    }
    if ( ! is_user_logged_in() ) {
    return new WP_Error(
    'rest_disabled',
    __( 'The WordPress REST API has been disabled on this site.' ),
    array( 'status' => rest_authorization_required_code() ) );
    }
    return $result;
    });

    With the code enabled, the WordPress REST API is available to authenticated users but is unavailable to unauthenticated users.

    View post on imgur.com

    Additionally, with this code enabled, the connection between my WordPress site and Wordfence Central is immediately broken:

    View post on imgur.com

    It surprises me that, in order to function correctly, Wordfence Central needs to make unauthenticated requests to my site’s REST API.

    Please help me to understand:
    – Why does Wordfence Central require unauthenticated access to my site’s REST API?
    – How can such a requirement be a ‘best practice’ secure implementation?
    – How does this relate to the onboarding process (‘Connect site to Wordfence Central’) where there is mention of sharing PKI keys?

    David.

    • This topic was modified 1 year, 2 months ago by David Adams. Reason: Typo
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support wfpeter

    (@wfpeter)

    Hi @tictag, thanks for getting in touch.

    We’re unable to support/evaluate custom code as future WordPress or Wordfence updates could result in changes being required further down the line, but I can certainly try to help with your query.

    To clarify the position of WordPress themselves on the REST API, their developer documentation states:

    “…the most important thing to understand about the API is that it enables the block editor and modern plugin interfaces without compromising the security or privacy of your site.”
    https://developer.www.ads-software.com/rest-api/

    Wordfence Central will never be a?logged in user?on your site when it visits, as it won’t have an account on?WordPress > Users > All Users. A request is made to obtain a?nonce?and hit an authentication endpoint to securely make a connection but it cannot get that far if it’s being served with a 401 with any level of request to any path on the REST API.

    Thanks,
    Peter.

    Thread Starter David Adams

    (@tictag)

    I imagine the WordPress REST API like ports on a firewall and, adopting the cyber security principle of ‘least privilege’, I would prefer to close all ports by default, then open them as required for known safe connections.

    How would I ‘open a port’ for this connection?

    Perhaps there are two options:
    (1) If you’re hitting a particular API endpoint, I could, instead of blanket disabling the entire API system, keep the one you need active.
    (2) If your connection request always contains a nonce, I could disable the API only for requests that do not contain a nonce.*

    Would either of these options satisfy Wordfence Central’s connection requirements?

    Note: I use MainWP to centrally manage my WordPress sites. I am not familiar with their secure connection design but I know that it works with my current configuration i.e. with the WordPress REST API disabled. If they can do it, why can’t Wordfence?

    *I am not a software developer and only barely understand what a nonce is (from reading the article you linked to) but it seems that a nonce must be generated by WordPress, then used by adding it to an inbound URL request – like a shared secret. If Wordfence Central is initiating the connection e.g. do a scan, how does it get the nonce?

    • This reply was modified 1 year, 2 months ago by David Adams. Reason: typo
Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Wordfence Central Requirement For Unauthenticated REST API’ is closed to new replies.