Content Security Policy (CSP) Questions for Web Payments SDK

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?

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:

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

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: