websavers

@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, 5 months ago by websavers.
• This reply was modified 3 years, 5 months ago by websavers.

@hchouhan Thank you!

Hey @hchouhan

Thank you, that’s exactly what I needed, particularly for the member types profile fields.

Just to confirm, you said only email address is sent by default… wouldn’t/shouldn’t it also include the person’s name since it is pulled from the WordPress user fields rather than BuddyPress xprofile fields?

Or are you saying I *do* need to connect the person’s name using that custom code because I’m using BuddyPress?

Cheers!

• This reply was modified 4 years, 9 months ago by websavers.
• This reply was modified 4 years, 9 months ago by websavers.

Hey there,

Front-end searching could be any number of issues, but if you’re experiencing SKU search problems *also* in the WordPress admin, check this WooCommerce Issue out for details on how to fix this up.

-websavers.ca

@vhfilgueiras You’re right – it *shouldn’t* be an issue. It is, however, the issue we’re having. In my testing, removing or cancelling these orders has released the stock and the cart functions properly again.

@fernashes – pending payment orders are holding stock despite hold stock being disabled.

@vhfilgueiras do you have any “Pending Payment” orders with those products? That’s what I’m finding on my end..

Confirming this issue still exists with all plugins disabled except WooCommerce.

Just to add a voice to this; we’re having the same issue on a client’s site and do not have the Jilt plugin mentioned above installed. Hold Stock is disabled on this site as well.

Just to make sure re:Hold Stock, I enabled it, saved, disabled it, saved, and checked – same issue.

Given that this client’s store has a number of single-stock items, it’s a really large issue at this point.

Moving on to further testing with a development site / disabling plugins, but wanted to note that it’s not an isolated incident with @vhfilgueiras’s site

• This reply was modified 6 years, 4 months ago by websavers.

It works perfectly, thanks so much!

(Company account, sorry for any confusion!)

• This reply was modified 7 years ago by websavers.