Sandbox Accept Hosted CSP issue

[cc-45335]

Greetings!

We use the Accept Hosted API for our C# based payment forms. Production is working fine. However, our testing forms suddenly appear to have stopped working when testing payments. I'm seeing the following in the console:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' blob: https://*.ads-twitter.com https://*.authorize.net https://*.bing.com https://*.ceros.com https://*.contentsquare.com https://*.contentsquare.net https://*.cookiereports.com https://*.doubleclick.net https://*.eloqua.com https://*.en25.com https://*.facebook.net https://*.google-analytics.com https://*.google.com https://*.googleadservices.com https://*.googletagmanager.com https://*.gstatic.com https://*.idio.episerver.net https://*.licdn.com https://*.linkedin.com https://*.optimizely.com https://*.twitter.com https://*.visa.com https://*.youtube.com https://api.company-target.com https://cdn-assets-prod.s3.amazonaws.com https://code.jquery.com https://company-target.com https://id.rlcdn.com https://optimizely.s3.amazonaws.com https://rlcdn.com https://s.company-target.com https://scripts.demandbase.com https://segments.company-target.com https://tag-logger.demandbase.com https://tag.demandbase.com". Either the 'unsafe-inline' keyword, a hash ('sha256-rQFcSQ+uPvBBS36Ebz2AA8DWF5LxdwuQKeLhxEfN+Ec='), or a nonce ('nonce-...') is required to enable inline execution.

And

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' https://*.authorize.net https://*.ceros.com https://*.eloqua.com https://*.google.com https://*.gstatic.com https://*.licdn.com https://*.optimizely.com https://*.visa.com https://fonts.googleapis.com". Either the 'unsafe-inline' keyword, a hash ('sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

I just noticed this issue on Friday. All of our test forms that were working previously in the last month seem to be having this issue (pointing to https://test.authorize.net/payment/payment). Our production forms that point to https://accept.authorize.net/payment/payment  work fine. It doesn't look like they are applying a CSP to the production environment.

If I go straight to https://test.authorize.net/payment/payment the same errors appear in the console there. Is authorize.net blocking their own script/styles via the CSP in the test sandbox? Is anyone else seeing this?

Thanks

[aleksandarilic]

Did somebody solved this issue?

[khurram2875]

I am also having the same issue https://test.authorize.net/payment/payment?token={token} did not work for me either

[evaelfie]

---

@cc-45335 wrote:

Greetings!

We use the Accept Hosted API for our C# based payment forms. Production is working fine. However, our testing forms suddenly appear to have stopped working when testing payments. I'm seeing the following in the console:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' blob: https://*.ads-twitter.com https://*.authorize.net https://*.bing.com https://*.ceros.com https://*.contentsquare.com https://*.contentsquare.net https://*.cookiereports.com https://*.doubleclick.net https://*.eloqua.com https://*.en25.com https://*.facebook.net https://*.google-analytics.com https://*.google.com https://*.googleadservices.com https://*.googletagmanager.com https://*.gstatic.com https://*.idio.episerver.net https://*.licdn.com https://*.linkedin.com https://*.optimizely.com https://*.twitter.com https://*.visa.com https://*.youtube.com :https://api.company-target.com https://cdn-assets-prod.s3.amazonaws.com https://code.jquery.com https://company-target.com https://id.rlcdn.com https://optimizely.s3.amazonaws.com https://rlcdn.com https://s.company-target.com https://scripts.demandbase.com https://segments.company-target.com https://tag-logger.demandbase.com https://tag.demandbase.com". Either the 'unsafe-inline' keyword, a hash ('sha256-rQFcSQ+uPvBBS36Ebz2AA8DWF5LxdwuQKeLhxEfN+Ec='), or a nonce ('nonce-...') is required to enable inline execution.

And

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' https://*.authorize.net https://*.ceros.com https://*.eloqua.com https://*.google.com https://*.gstatic.com https://*.licdn.com https://*.optimizely.com https://*.visa.com :https://fonts.googleapis.com". Either the 'unsafe-inline' keyword, a hash ('sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

I just noticed this issue on Friday. All of our test forms that were working previously in the last month seem to be having this issue (pointing to :https://test.authorize.net/payment/payment). Our production forms that point to https://accept.authorize.net/payment/payment  work fine. It doesn't look like they are applying a CSP to the production environment.

If I go straight to :https://test.authorize.net/payment/payment the same errors appear in the console there. Is authorize.net blocking their own script/styles via the CSP in the test sandbox? Is anyone else seeing this?

Thanks

---

It appears that Authorize.Net has recently updated the Content Security Policy (CSP) on their sandbox environment to be significantly stricter. As you've observed, the CSP is now blocking inline scripts and styles unless they are accompanied by an appropriate nonce, hash, or the use of unsafe-inline which is generally discouraged for security reasons. This is why your test forms are now failing while your production forms , which still allow inline scripts/styles, continue to work as expected.

[edwardharry]

I have seen similar CSP issues when browser security changes start enforcing policies that were not causing problems before. I would first compare the exact CSP error in Chrome and Edge and check whether the required CyberSource domains are allowed by the current policy. Testing the integration in a clean browser profile could also help rule out extensions or cached settings as the cause.