Do you think that having website under https:// is a sufficent protection for the data transmission ? Yes and no because even the smallest mistake can compromise all security measures. One of these "smallests mistakes" is a browser warning, known as mixed content.
New ebook 🔥
Learn 84 ways to solve common data engineering problems with cloud services.
This article will help to understand the risk caused by mixed content page. Its first part will describe a theoretical aspect and a potential attacking schema. In the second part, we'll how to provoke this error and which are the ways to fix it.
What is mixed content page ?
An issue called mixed content page accessible under https:// but containing links to insecure resources (usually under http://). That can produce an alert message from the browser with content like "Do you want to view only the webpage content that was delivered securely ?" (IE). To simplify, it means "if you want to see only the content delivered under https:// protocol".
Also, you can introduce this issue incidentally because of caching. The content transmitted under https:// isn't cached. If it was, imagine that somebody who bought your computer, would be able to see, for example, financial report of your company or other very private things. Instead of caching HTTPS content, the browser will very often use RAM memory to serve it to the user.
Additionally, mixed content page produces browser warnings with the messages like at the begin of this article. These warnings are purely non-user friendly practice.
How to fix mixed content page ?
If your webiste makes the links to other domains which are non-secured (http://), you can copy the content of these links and save them under your domain. To prevent hosting of obsolete data, you could write a small script which will be download current version of linked resource every night.
And finally, make sure that your webpage content is secure. For example, you can use HTMLUnit to simulate user navigation and checks if all resources (<script />, <link />, <img /> etc.) are loaded through https://. Don't forget to make some real tests by navigating in your website.
This article shows very well why the developers shouldn't ignore the warnings. Not only the warnings in server logs, but also the warnings belonging to client side (browser). Thanks to it, all effort made on securing a website in server-side won't be a waste of the time.