I have implemented the Web Payments SDK. I have everything set up correctly including CSP etc. but customers are regularly seeing the card form fail to initialise
In developer tools under Network I am seeing various blocked resources but it varies by browser.
In Firefox there are multiple NS_ERROR_DOM_NETWORK_ERR for pci-connect.squareup.com but these errors don’t appear in Chrome nor Edge.
Can you verify/paste the contents of your CSP here? Could you also post the exact error message(s)?
You can validate your CSP here to make sure its being loaded appropriately https://csp-evaluator.withgoogle.com/ as well. I tested the documented CSP in my local app in chrome and firefox without issues.
Some resources are blocked because their origin isn’t listed in your site’s Content Security Policy (CSP). Your site’s CSP is allowlist-based, so resources must be listed in the allowlist to be accessed.
A site’s Content Security Policy is set either via an HTTP header (recommended), or via a meta HTML tag.
To fix this issue do one of the following:
(Recommended) If you’re using an allowlist for 'script-src', consider switching from an allowlist CSP to a strict CSP, because strict CSPs are more robust against XSS. See how to set a strict CSP.
Or carefully check that all of the blocked resources are trustworthy; if they are, include their sources in the CSP of your site. Never add a source you don’t trust to your site’s CSP. If you don’t trust the source, consider hosting resources on your own site instead.
Having gone into all the above, in general the form does still load and work despite the CSP errors, BUT
there are frequent fails to load the SDK js (my code tries several times if it fails, but this takes time and I can’t see why the fail rate?)
there are fails to initialise - or it takes a very long time. The Dom is ready and the card fields available when the initialise is called so it’s not that… (again, my code repeats the request if needed)
connect-src is missing entirely. Without it, default-src 'self' applies, blocking all connections to pci-connect.squareup.com and web.squarecdn.com.
Add the below and any other support payment CSPs from the doc above:
img-src doesn’t include web.squarecdn.com which likely causes the info-icon.svg load failure.
Add:
https://web.squarecdn.com to the existing img-src.
Potential issues:
script-src uses 'strict-dynamic'. With strict-dynamic, allowlist entries like https: are ignored in supporting browsers. The SDK script at https://web.squarecdn.com/v1/square.js will only load if it’s given the correct nonce attribute, or if it’s dynamically injected by an already-trusted script. Make sure the script tag loading square.js has the matching nonce attribute:
require-trusted-types-for 'script' can interfere with the SDK’s internal DOM manipulation if it uses innerHTML or similar APIs. If you see Trusted Types violations in the console after fixing the above, you may need to add a policy or remove this directive on the payment page.
These look fine:
• frame-src — https://*.squarecdn.com correctly covers the SDK iframe
• style-src — https://web.squarecdn.com and 'unsafe-inline' are both present
Argh SORRY, the CSP I pasted above was copied from the browser dev tools rather than my code, and seems to have been truncated. I appreciate your reply above but the full CSP is as follows, and has always contained the connect-src, font-src, and img-src you’ve suggested I add.
I also removed the require-trusted-types-for 'script' which was suggested by the Google CSP evaluator (that you suggested above) before most of my replies above.
And yes, all calls include the nonce attribute, I’m well aware of that.
Please would you reply again having looked at all my replies, and bearing in mind they are all based on the following CSP rather than the truncated one above (sorry again)
Please take a look at your suggested font-src because the errors I’m getting are due to the CSP within the injected single-card-element-iframe.html:0 which overrides the site CSP (and therefore my CSP can’t solve) and is missing https://cash-f.squarecdn.com for font-src
I can reproduce the the font errors from the square iframe itself, it shouldn’t affect anything payment wise and I don’t see any issues on the rendering either.
Have you checked the exact CSP loaded on your page? Located in the DevTools > Network > Initial page request.
There might be a default CSP applied to the HTML. The browser chooses the stricter of the CSPs loaded on the page.
How is your site being loaded? Do you have access to the parent site or are you trying to embed your payment html in an iframe (i.e., main website window > custom square payment iframe > square card iframe)
You can DM me a link to the page if possible, I can do a quick gander but no promises unfortunately
If all else fails, I highly recommend trying to reproduce with the quick start app. It’s very basic which will help isolate any issues.
This might not affect the rendering, but given that Square insists on the correct CSP, it’s more than a little ironic that it’s not totally correct on your side…
I code and control the website. I’m using the JS Web Payments SDK with PHP. No iframes. I can DM you the link but you’d have to create an order to see the page.
Is there a sample page at a particular URL that I can look at, or do you mean going through all the github stuff?
Sorry for this wild goose chase! I took a look at your site and went through the booking process to check out the payments page. I thought you were getting CSP errors form https://pci-connect.squareup.com/payments/mtx/v2 but they are network errors. Is that what you are seeing?
I re-tested my site on firefox and I get the same network errors. If you inspect the stack trace of the network calls you can see they are metric logging calls and not critical to the load/usage of the card endpoint.
Is anything about the card payment not working? Or does what I said above track?
And the font stuff can be ignored, I’ll ask the devs about it and see if we can’t resolve that on our end.
Yes I guessed that was the case re those - I have a lot of programming experience, but am a little bit in the dark with network traffic sorry. I still think it would be good for Square to sort out the CSP font errors, but I understand they aren’t breaking it.
The card payment seems to work in most cases, but I am seeing page reloads where the card form takes some seconds to initialise and populate.
I’ll keep an eye on it as I’ve re-written the logic just now to load the js earlier. Won’t help with slow/failed initialise but we’ll see.
No problem! I tend to only monitor the console in dev tools and never look at network unless my specific API isn’t working haha.
For the card form load timing all I can say is make sure the script itself is loading from a browser cacheable script source. I couldn’t find its script tag but I also didn’t look too hard. On my local app I eagerly load all of the payment frames at checkout so the delay isn’t noticeable.
Never add a source you don’t trust to your site’s CSP. If you don’t trust the source, consider hosting resources on your own site instead.
