Changing Content Security Policy might overwrite defaults

[antpb]

After changing my content security policy in an instance, I found that reverting to the default values of blank results in some errors on every page stating that the content security policy is blocking resources. Here's a snippet from my console

Content Security Policy: Couldn’t parse invalid host wss://:80
Content Security Policy: Couldn’t parse invalid host https://:80
Content Security Policy: The page’s settings blocked the loading of a resource at data:application/javascript;base64,KCgpI… (“script-src”).
<script> source URI is not allowed in this document: “https://www.google-analytics.com/analytics.js”.

I'm also seeing further down the console the following error

Content Security Policy: The page’s settings blocked the loading of a resource at https://bp-hubs-assets.<internaldomain>.com/...

Is there anywhere I may find the default values of these to put in the admin server settings for script-src?
I'm having a lot of trouble reverting to a previous state. I could delete the entire instance and start over, but I figure this may be something other folks could hit so best to solve it.

[antpb]

I went ahead and created a new instance after deleting the old one and I'm seeing the same issue. I thought maybe it was cache so tried on another computer to verify. You can see yourself here: https://hubs.broken.place

I'm also seeing it in Spoke on the above instance and locally checked out to the master branch. In my local, the cors errors look like:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://hubs.local:9090/sockjs-node/info?t=1599707973705. (Reason: CORS request did not succeed).

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://hubs.local:9090/sockjs-node/info?t=1599707975769. (Reason: CORS request did not succeed).

[antpb]

On my live instance ( https://hubs.broken.place ) I've deployed the latest hubs-cloud branch to be certain, but still seeing the following on home page:

The source list for Content Security Policy directive 'connect-src' contains an invalid source: 'wss://:80'. It will be ignored.
hubs.broken.place/:1 
The source list for Content Security Policy directive 'connect-src' contains an invalid source: 'https://:80'. It will be ignored.

I cant figure out how a fresh new instance would be still doing this. I've dumped every cache I know of, including Cloudflare things. This one is weird! :D

[robinkwilson]

The source list for Content Security Policy directive 'connect-src' contains an invalid source: 'wss://:80'. It will be ignored.
hubs.broken.place/:1 
The source list for Content Security Policy directive 'connect-src' contains an invalid source: 'https://:80'. It will be ignored.

^^ This is a known issue, I believe it even happens on hubs.mozilla.com.

Do you find it interfering with any of your hubs functionality? Double check if you can still hear other people.

Content Security Policy: The page’s settings blocked the loading of a resource at data:application/javascript;base64,KCgpI… (“script-src”).
<script> source URI is not allowed in this document: “https://www.google-analytics.com/analytics.js”.

AND

Content Security Policy: The page’s settings blocked the loading of a resource at https://bp-hubs-assets.<internaldomain>.com/...

^^ These are interesting.

To repro, what steps did you take?
If you can add this as an issue with your reproduction steps in https://github.com/mozilla/hubs-cloud/issues we'd greatly appreciate it!!
Please include: which setting you changed + whether you deleted it from the Parameter Store + Any other steps.

[antpb]

I did some digging and documenting here: Hubs-Foundation/hubs-cloud#107

This is starting to feel like a cleanup issue from the old stack. When creating a new stack on the same domains (and cleaning up old record) it still produces Content Security Policy errors.

You can reproduce the error most clearly by going to https://hubs.broken.place/spoke and making a new scene. When you've reached the new scene, add a video element and use a youtube/vimdeo url and you'll notice that videonode fails. The instance is currently what deploys with a new stack as of last night.

[johnshaughnessy]

Marking this as the answer to the question so that discussion moves to the issue you created