Cross-domain error on same domain.

May 10, 2023 3:48 PM

Getting: Uncaught DOMException: Blocked a frame with origin "https://domain.com" from accessing a cross-origin frame at https://domain.com/resource" even though they're both same protocol, domain and port.

Firefox reports the same error as: "Uncaught DOMException: Permission denied to access property "wwp" on cross-origin object"

We are aware of CORS headers issues and have it configured correctly according to 'https://cors-test.codehappy.dev/'. The thing I can't understand is why this is giving me a cross-origin error even though portocol, domain and port match.

posted by signal to Computers & Internet (11 answers total)

I assume you're getting the errors from the browser console. I would look at the network view to see exactly which request is failing, and then look at the headers for the request and the server response to see if the origins actually match.
posted by zippy at 4:11 PM on May 10, 2023

Is it possible that one of your pages is setting the document.domain property to a different value?
posted by teraflop at 5:38 PM on May 10, 2023

I would look at the network view to see exactly which request is failing, and then look at the headers for the request and the server response to see if the origins actually match.

It doesn't seem to be faiing on any file, but rather while trying to access a property on a remote javascript file.
posted by signal at 5:58 PM on May 10, 2023

Use `curl` or `wget` to perform the request and inspect headers. You and/or your CORS tester may be missing something.
posted by They sucked his brains out! at 6:11 PM on May 10, 2023

I feel like talk about CORS and the network tab are in the wrong direction. Is this an error raised when Javascript in one frame tries to access another one? Is the scenario that one page iframes another, or is it more complicated?
posted by Horselover Fat at 6:59 PM on May 10, 2023

It's an office add-in running in Excel on office.com. The error seems to be trying to access a remote object (in a javascript file) from within a frame, even though the javascript and object and the frame are on the same domain.
posted by signal at 5:44 AM on May 11, 2023

Just to clarify: I don't think the error is requesting a file, but rather executing a remote function, if that makes any sense.
posted by signal at 5:45 AM on May 11, 2023

Having had to do this at work recently, try

curl -H "Origin: https://domain.com" --verbose https://domain.com/path/to/problem

Actually, in our case it was hit or miss due to different containers, so I collected the response code over 100 runs by doing the following

for i in {1..100}; do curl -H "Origin: https://domain.com" -s -o /dev/null -w "%{http_code}" https://domain.com/path/to/problem; done
posted by yerfatma at 11:19 AM on May 11, 2023

So apparently there's an issue with loading the site in an iframe and haing it execute code on a remote javascript. I tested this locally with a dummy html file and I get the same error as when loading it on office.com.
posted by signal at 12:08 PM on May 11, 2023

If the two resources that are mentioned in the error are on office.com, I think "same domain" is going to act more restrictively than a normal server on a domain you control (to prevent cross site shenanigans from malicious tenant A on Fortune 500 tenant B's webmail portal, for example)

I am not a JS dev, so my apologies for speaking in network and HTML terms. Map this as appropriate to your situation. For both resources in the error message I would look at the page's frame permissions and the server policy headers returned when those frames are fetched to see if office.com is allowing these to be treated as "hey, we're all on the same domain, it's all good" or not.
posted by zippy at 12:24 AM on May 12, 2023

Specifically the content security policy settings in the frame(s) and in the server headers.
posted by zippy at 12:51 AM on May 12, 2023