• Hello guys,

    Recently i did a site for a client. After receiving it the client sent the site for acunetix security check, which brought back this alert.

    —-acunetix alert—

    Access-Control-Allow-Origin: https://www.example.com
    Access-Control-Allow-Credentials: true
    
    Any origin is accepted (arbitrary Origin header values are reflected in Access-Control-
    Allow-Origin response headers). For the WordPress /wp-json/ endpoint, this may be
    
    the intended behavior and requires manual review. For further information, please
    refer to the WordPress REST API Handbook linked in the "References" section below.

    — the end of acunetix alert —

    i finally found where this is located – in rest-api.php

    function rest_send_cors_headers( $value ) {
    	$origin = get_http_origin();
    
    	if ( $origin ) {
    		// Requests from file:// and data: URLs send "Origin: null".
    		if ( 'null' !== $origin ) {
    			$origin = esc_url_raw( $origin );
    		}
    		header( 'Access-Control-Allow-Origin: ' . $origin );
    		header( 'Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE' );
    		header( 'Access-Control-Allow-Credentials: true' );
    		header( 'Vary: Origin', false );
    	} elseif ( ! headers_sent() && 'GET' === $_SERVER['REQUEST_METHOD'] && ! is_user_logged_in() ) {
    		header( 'Vary: Origin', false );
    	}
    
    	return $value;
    }

    Can anyone let me know what should i do in this case.
    thank you so much in advance.

    The page I need help with: [log in to see the link]

Viewing 3 replies - 1 through 3 (of 3 total)
  • Don’t edit WordPress core files.

    You can easily set whatever CORS policy you want either directly on your server, or via WordPress functions.

    Here’s a tutorial on how to customize the Access-Control-Allow-Headers property for your WordPress REST API via your theme’s functions.php file:

    https://linguinecode.com/post/enable-wordpress-rest-api-cors

    Be sure to thoroughly test whatever policy you end up using though, so you don’t inadvertently deliver a broken website to your client.

    Thread Starter glaukabazi

    (@glaukabazi)

    Do you have any idea why wordpress is using this policy, if it is high alerted by acunetix. Should this fix be already there by wordpress?

    Thank you

    @glaukabazi that is a great question. And from what I can tell, yes this should be fixed by WordPress. In theory, my understanding of this flaw is that a malicious user could set up a MITM attack by:
    1. Setting up their own web server that proxies all wp-json queries (or REST API in general)
    2. Configuring that server to include its own domain as the Origin value in the request
    3. Because of (2), the server hosting WordPress would then allow that malicious origin to retrieve and show the data on the malicious domain

    Now, normally this isn’t a big deal because the wp-json data showing is public data anyway. However if the mailcious user tricks an already authenticated user (authenticated with WordPress through normal mechanisms on the real/live WordPress domain) to then access their mailcious URL, the malicious server could then capture json data which is private and expected to be only available to the logged in user.

    My guess would be that the solution here is to, at bare minimum, not have this header present:

    header( 'Access-Control-Allow-Credentials: true' );

    OR perhaps better yet to have a setting in WordPress where you configure the allowed origin domains and unless it’s explicitly set by the site owner, these headers are not added at all. When it is set, it only applies to the configured origin and not an arbitrarily set origin from the request data.

    If you’re setting the CORS headers yourself in the web server config, you can use this in your functions.php or the Snippets plugin to disable these headers:

    //Remove CORS headers for REST API that allow arbitrary origins
    add_action( 'rest_api_init', function($var){
    	remove_filter( 'rest_pre_serve_request', 'rest_send_cors_headers' );
    }, 15, 1 );
    • This reply was modified 3 years, 1 month ago by websavers.
    • This reply was modified 3 years, 1 month ago by websavers.
Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘CORS (Cross-Origin Resource Sharing’ is closed to new replies.