Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 '' was loaded over HTTPS, but ran insecure content from this content should also be loaded over HTTPS.

The request URL is // 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?

share|improve this question
As David pointed out, SoundCloud is redirecting requests at to Since https is dropped, your browser will complain of insecure content. – Question Overflow Aug 24 '14 at 7:33
It seems that the issue has been resolved by soundcloud by now. – Yogu Aug 24 '14 at 21:21
Web security strongly relies on hostnames. And a hostname is not the same as -- browsers and SSL certs are very strict about this. (And there are right and wrong ways to configure servers to handle these discrepancies. Sometimes mistakes, like a faulty 301 redirect, cause errors like this.) – Matt Aug 25 '14 at 3:57
It should be noted that the Chrome error message is rather bad too, because it complains about loading insecure content from what looks like perfectly valid secure URL without mentioning the bad redirect anywhere. – Jan Hudec Aug 25 '14 at 6:21
You know nothing. – Lightness Races in Orbit Aug 25 '14 at 12:50
up vote 88 down vote accepted

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 to with a 301 redirect. The problem is that they are redirecting all traffic to 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.

share|improve this answer
Alright I'll rephrase the question. – Jon Snow Aug 24 '14 at 6:56

Your browser is showing this warning because Sound Cloud apparently has incorrectly configured redirect for the following URL:

redirects to:

Notice the normal "http". This is why the browser is raising a red flag when embedded inside another https-based website/page. Whereas,

is not getting redirected and thus remains on the secure side of http.

share|improve this answer

The observation and behavior is correct, but the conclusion is wrong. The SSL certificate is issued in two ways

  1. To the site. In your case . As per the naming convention, and are two different names. Hence https site accessed with, it denied saying the certificate is not issued to . This does not mean there is issue or it is unsafe. The data is still going over SSL layer and provides same protection when accessed over

  2. In corporate sites, the certificate is issued to wildcard domains. But the wildcard certificates are very expensive and hence, most customers avoid going with wild card. In wild card case, the certificate is issued to *.domain. In your case if the certificate is issued as * then or all will work. even will also work.

I appreciate you brought a very good topic for discussion, but one need to understand the entire SSL certificate, domain , naming behavior in this case.

Many times, improper configuration of root certificate chain in server leads to error as well.

share|improve this answer
It is true and are different for cert name matching. But the error message here was clearly mixed content, not cert name mismatch. And the cert for this site (from GlobalSign DV SHA2 G2) has SubjectAltNames specifying BOTH and * Further, *.foo matches and '` and '` but not plain foo; see RFC 2818 and… . – dave_thompson_085 Aug 27 '14 at 8:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.