I was doing some cross-origin requests to  Soundcloud's oEmbed and I noticed some strange behaviour.
When doing a request from my localhost, which is on a regular HTTP connection, everything worked fine. However, when the code got pushed on our HTTPS test server, I got the following error from my browser:


  [blocked] The page at
  'https://example.com' was loaded over
  HTTPS, but ran insecure content from
  https://www.soundcloud.com/oembed?url=https://soundcloud.com/gwatsky/pumped-up-kicks-remix&format=js&callback=JSON_CALLBACK: this content
  should also be loaded over HTTPS.


The request URL is //www.soundcloud.com/oembed?url=https://soundcloud.com/gwatsky/pumped-up-kicks-remix&format=js&callback=JSON_CALLBACK. Note the "www.". 

I tried specifying the protocol to HTTPS and removing/specifying the protocol in the url parameter, but I kept getting the error.

In the end I removed the www. from the URL and everything started working fine.

tl;dr Why is having www. in this HTTPS URL considered a security risk?

I think you are making a huge assumption with your question:


  Why does Chrome consider the "www." in an HTTPS url as a security risk?


as this is simply not the case. 

What is happening is that SoundCloud is forcing users from www.soundcloud.com to soundcloud.com with a 301 redirect. The problem is that they are redirecting all traffic to http://soundcloud.com regardless of the originating protocol. 

This is simply a configuration issue with the Soundcloud website and has nothing to do with browser or web security standards. There is no inherent risk with the www subdomain to a website. 

The solution as you have already figured out is to remove the www in order to avoid the redirect. You might want to make the site's administrators aware of the issue if you are so inclined. 
