AUthorize.net hosted payment page not working in Chrome Version 60

[debasishbose2k]

We are getting this error

on the click of submit on the hosted payment form.

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://xxxx.xxx.com') does not match the recipient window's origin ('null').

I read some documentation in internet and noted the problem there mentioned as well . Adding for reference
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/fsDaKFqvU20

The hosted payment iframe failing Chrome60 , but is working in other browsers (namely Firefox/IE)

Please advise ,

[Aaron]

Thanks @debasishbose2k, @NexusSoftware, and everyone else on this thread for sharing your experiences. We've got a good understanding of the challenges now. From a documentation perspective, we'll try to come up with ways to help people understand the ins and outs of frame security and give some recommendations. We also have engineers looking at what possible solutions we can implement on our end.

Again, thanks!

[vallapus]

Hi,

Thanks for posting the solution.

I have a question related to this. Since X-Frames is deprecated, does CSP server the same purpose from other servers to not allow framing.

[Aaron]

Hi @vallapus,

It's my understanding that it does, but it may not be as simple as just replacing one header with another, depending on which browsers you're trying to support. You may have to determine whether your targeted browsers all support the aspects of CSP that you want, and if not, come up with some hybrid approach.

[raviparmarce88]

@Aaron,

We are also facing same issue.

Could you please update the implementation document with some proper hybrid approach.

Also it would be helpful if authorize.net publish this on news and update page.

I will try with the solution suggested by @NexusSoftware and come up with result.

[Aaron]

Hi @raviparmarce88,

Thanks for the input.

This isn't really a problem specific to us, but to anyone using any CSP headers or X-Frame-Options on their sites. If you don't use those headers, there's no problems with our forms, and if you do, you will run into different behavior on newer browsers when you start getting into frames within frames like this, whether we're involved or not.

If someone runs into that problem with our services, we still want to help them as much as we can, though. I'll make sure we at least address this in our developer FAQ, although a blog post would be a good idea. I'd like to encourage more people to think about security anyway, so a blog post walking someone through the "right" way to lock down our frames would definitely be useful.

[ioiki]

 i m also getting same error on Chrome browzer..

Refused to display 'https://mysiteurl.com/scripts/IFrameCommunicator.html#action=resizeWindow&width=736&height=401' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
15:20:54.600

Any Sloution on this...

[daskjeeves]

Any ideas on this? I've read through all the posts on the iframe on the forum and not having much luck getting the communicator to work because of the 'sameorigin' issue

[Vikas_chauhan]

 am also getting this issue recently in my chrome Version 67.0.3396.99 (Official Build) (64-bit).

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided (server URL on https) does not match the recipient window's origin ('https://test.authorize.net').

same for production.

[introin]

Hey fellow Developers, 
I too face the similar issue. 
I am using hosted form in Laravel framework. 
Now tricky part is that I am only getting this issue when iframecommuicator return url is under Laravel auth. Post removing from auth, it is working fine and no domwindow or corss origin error. 

I have tried adding "allowing cross origin requests in Laravel routes too" with no success. 

If any one can suggest configuration or setting here specifically to get rid of this issue. 

P.S. This issue only happens in chrome and not in firefox. 

[jfkrueger]

We are having the same issue and applying the content-security-policy via web.config file (asp.net/IIS) is not working. We are passing a paymentProfileId in the token.

• We are still seeing the error in the console.
  • Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('our domain') does not match the recipient window's origin ('auth.net domain')
• The payment gets cut off and is not the correct size so you cannot see all of the fields.
• The purchase window does not close after a purchase.

Example of web.config:

<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="frame-ancestors 'self' https://localhost:44300 *.ourdomain.com *.authorize.net" />
</customHeaders>
</httpProtocol>

We have even tried with the Content-Security-Policy-Report-Only but still no luck, it acts the same. 

What can we do when the content-security-policy is not working?