Can't load a script from a cdn?

I am trying to load lodash via a cdn and am getting the following error.

Does this mean that we can’t use any cdns at all?

Domain violates Zoom App Marketplace domain policy. Reason: Domain permits serving user-generated content.

The domain should be added to “domain allow list” in marketplace build flow (where you configure your app).

For example, if I am loading SDK from CDN , I would add it like this

Thanks Narmada, that’s where I was adding it and where I was seeing:

Domain violates Zoom App Marketplace domain policy. Reason: Domain permits serving user-generated content.

@RostislavR We’re checking with our security team and will update you when we have more info.

1 Like

We recently started noticing the same for our CDN. In our case it is against

Same now with trying to load preact from a cdn.

So basically our only option is to serve all files ourselves?

Greetings! Any chance we can get an update on this one? :pray:

Hi, we are having similar issues with I want to show flutter web page on zoom client which need to have
but apparently it is not allowed.

Domain violates Zoom App Marketplace domain policy. Reason: Domain permits serving user-generated content.

How should we deal with this?

I’m having similar issues as well, where I’d like to render my company’s page in the zoom client, but the assets are delivered by a CDN. And unfortunately, the CDN domain (cloudfront) is blocked by the Zoom App Marketplace.

Any way we can get an update on how to solve this issue?

We’re facing the same issue after migrating to GCP. Trying to add to the allowed domain list and getting the same issue. Users are now unable to upload or download any files on our app. Can you please suggest what to do here @MaxM?

@osho.chawla @briansui21
While the Zoom team looks into resolving this issue, I found a temporary workaround. I am using nginx reverse proxy of my server. (NGINX Reverse Proxy | NGINX Plus).

Here is the code addition in my server’s nginx config


   location /  {
  proxy_buffering off;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Port $server_port;

This would at least unblock you and start loading the script. The downside is that you may have to add rules for each such domain individually and need to update the frontend as well to point to the new address. Also, script load time would be slightly longer now.

You’ll want to download and serve those resources locally. If possible, I recommend using the npm package:

If possible, I would create an API endpoint on your server that wraps the functionality of the storage API.

Can you confirm if this would work for your use case?

Yes, a generic storage API as a proxy would also work. I did not want to do a new backend deployment. Moreover, my proxy solution helps me separate server load with static files and storage load when we hit the scale. I can keep a dedicated server just for proxy traffic without interfering with my primary server traffic.

The real problem is, why is Zoom not allowing access to certain domains? If this was for security, the domains can any which ways be reached via the above methods. Why make it hard for developers in the approval process?

This is a great question. I think overall the decision was made to prevent bad actors from adding user-generated to the Zoom Client but as you mentioned there are methods to get around this restriction. However, in most cases that requires a change to a backend component rather than frontend code. In other words, there is another layer of security.

I’ve posed this question to our marketplace team to see if I can gain further information or we can make any changes in this regard.

As an update, our team will be discussing this next week as part of their team meeting. I’ll be sure to keep you informed.

Hi @MaxM Any update on this? I am using a third party library which uses to host some of their content and this domain is being blocked by the Zoom client. I cannot modify their script. Appreciate any help here.

This issue is being actively discussed by our leadership and product teams. They are working towards a solution and we will implement it once we have finalized our plan.

Unfortunately, that is the extent of information that I have available at this time but we are working on a solution for this.

Is there an update now? I mean, serving all cdn files on our own is not the greatest idea…

I see the same issue happens, so I’m not sure.