Content Security Policy (CSP) Questions for Web Payments SDK

Questions
1

Hello,

I’ve seen a few posts on this forum, and the official developer documentation, regarding Square’s CSP. Unfortunately, the developer docs do not account for every resource that is queried by the Square API. I’m writing this post to get a better idea about the CSP directives I’m missing.

I’ve gone through the payments flow a few times in Sandbox, but I’ve missed a few domains in the CSP when I launched in production. For instance, some of my customers had CSP violations for geoissuer.cardinalcommerce.com, which is not listed in the SquareUp developer docs.

Can we get a better idea to what the real CSP should be? I’m trying to prevent my application from breaking for future edge cases that I’m not accounting for (like SCA verification).

Here’s a snippet from my Python code which describes my current CSP:

        csps = {
            "connect-src": [
                "https://connect.squareupsandbox.com/",
                "https://connect.squareup.com/",
                "https://pci-connect.squareupsandbox.com/",
                "https://pci-connect.squareup.com/",
                "https://o160250.ingest.sentry.io/",
            ],
            "frame-src": [
                "https://*.squarecdn.com/",
                "https://connect.squareupsandbox.com/",
                "https://connect.squareup.com/",
                "https://api.squareupsandbox.com/",
                "https://api.squareup.com/",
                "https://geoissuer.cardinalcommerce.com/",
            ],
            "script-src": [
                "https://*.squarecdn.com/",
                "https://js.squareupsandbox.com/",
                "https://js.squareup.com/",
            ],
            "style-src": ["'unsafe-inline'", "https://*.squarecdn.com/"],
            "font-src": [
                "https://*.squarecdn.com/",
                "https://d1g145x70srn7h.cloudfront.net/",
            ],
        }

I worry about creating a complicated CSP due to resources from many different domains. For instance, I was not expecting d1g145x70srn7h.cloudfront.net, and your developer docs don’t account for it either. Is there any way that future versions of the Web Payments SDK trim some of the API calls to third party domains?

2

When your customer got the error geoissuer.cardinalcommerce.com were they going through the verifyBuyer 3DS? If so this is expected and we don’t document every domain cause we would have to document every bank domain for the verification process. :slightly_smiling_face:

3

Ah, I see. As a security engineer, I’m a little reluctant to relax the CSP. Do you have any recommendations for me outside of this?

I’m not sure I see a good path forward for implementing SCA without relaxing CSP, if this is the case. I suppose I could allowlist domains that violate the CSP as I see them, but I’m trying to avoid the user experience hit.

1 Like
4

Unfortunately, we don’t have any other recommendations. Since the verification goes through the banks domain you would need to either enable every banks domain or relax CSP restrictions. :slightly_smiling_face:

5

@ccerne I have run into a CSP issue and your expertise is required!

I just want to allow the following:

Screenshot 2024-04-07 at 10.59.54 am
Screenshot 2024-04-07 at 10.59.54 am1998×272 83.2 KB

This has been bugging me and unable to create solution: Using React and javascript

6

Are the same errors showing when you run it in production? :slightly_smiling_face:

7

Yes! I’ve changed the scripts in production so they load the correct ones, however I still get POST https://pci-connect.squareup.com/payments/mtx/v2 net::ERR_BLOCKED_BY_CLIENT

I’m unable to process a payment using production credentials

8

Hmm, okay and you set this up as per Seeeds documentation? You may want to reach out to them about this since they’re the ones that build the React Web Payments SDK. :slightly_smiling_face: