topic Re: Sandbox Accept Hosted CSP issue in Integration and Testing

Sandbox Accept Hosted CSP issue

cc-45335 — Mon, 24 Feb 2025 18:13:06 GMT

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&colon; 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

Re: Sandbox Accept Hosted CSP issue

aleksandarilic — Fri, 07 Mar 2025 20:16:05 GMT

Did somebody solved this issue?

Re: Sandbox Accept Hosted CSP issue

khurram2875 — Fri, 09 May 2025 18:29:27 GMT

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

Re: Sandbox Accept Hosted CSP issue

evaelfie — Sat, 24 May 2025 20:49:41 GMT

@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&colon; 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.

Re: Sandbox Accept Hosted CSP issue

edwardharry — Fri, 18 Sep 2026 15:01:47 GMT

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.