I'm dealing with a phpBB forum user who wants to set up SSL on their entire site to secure user credentials and "private" parts of the website.

However, they want to preserve the traditional forum user experience of user generated img tags to offsite content, which triggers a browser mixed content warning. The only solution we've come up with is an SSL granting proxy. After pondering the problem for a while now, I'm curious why do browsers warn specifically about images? I understand the case for javascript, but images?

5 Answers 5


I would assume your reasoning is something like, "If the person constructing the page chose to send some of its images insecurely, then the browser should respect that this decision was done for a reason and allow it without a warning. The page is as secure as the entity providing it wanted it to be."

By contrast, the reasoning of the browser developers is something like, "We are putting a secure icon on the page as seen by the user and the user should be able to assume that means the whole page is secure. If some part of it isn't, the user deserves to know that."

Both arguments are valid, they're just different interpretations of what it means for a web page to be secure.

There are specific risks with images too. The image is requested in the clear using the HTTP protocol. This discloses any information in the URL or headers. The most serious threat is that the image could contain instructions or information that the user would assume securely originated from the site the user chose. This could be used for phishing attacks.

  • So is there any particular security argument against using the proxy linked in the question?
    – jldugger
    Commented Jul 14, 2012 at 20:12
  • 1
    @jldugger: Only that in a sense you're "vouching" for the content you proxy by providing it to the user on a secure page. So one could make an argument that you have an obligation to ensure it's safe. (Or warn the user.) Commented Jul 15, 2012 at 1:41
  • Thanks, @DavidSchwartz, makes sense! I'm deleting my earlier comments now.
    – D.W.
    Commented Jul 15, 2012 at 23:52
  • @DavidSchwartz "Also, for a typical forum, an untrusted person can choose and control the URL and can use it to gain information they're, arguably, not entitled to." In a forum, messages and their content are untrusted user content by definition. I don't understand which specific threat exists with http: images in a forum accesses over https:.
    – curiousguy
    Commented Jul 16, 2012 at 3:23
  • @DavidSchwartz "So one could make an argument that you have an obligation to ensure it's safe." as in "safe for all the family", or "safe for your computer"?
    – curiousguy
    Commented Jul 16, 2012 at 3:24

The browser doesn't know what type of information an image or other resource is supposed to convey: perhaps it's just a logo, or perhaps it's some piece of UI, or perhaps the image is the whole point of the page you're visiting. There's no way for the browser to know whether a resource is important or not to the user.

When the primary (page) URL is loaded with HTTPS, then the browser signals to the user that the page being viewed is secure, usually with a lock icon, or green URL bar, or something like that. It doesn't say, "this page is secure except for that one image there" -- there simply isn't a mechanism to indicate to the viewer which parts are the insecure parts. So instead the resolution is that if the browser says that the page is secure, then ALL elements on the page must be secure, or the user has to be notified of the exception.

Note that viewing an insecure URL with a few secure elements generates no notifications or warnings, but at the same time there is no signaling to the user that there is any measure of security on the page. Since there is no expectation of security, the presence of mixed content is not noteworthy.

  • "there simply isn't a mechanism to indicate to the viewer which parts are the insecure parts." which is a problem, because there are mixed-content pages, and the user might get used to the warning and disregard it.
    – curiousguy
    Commented Jul 18, 2012 at 3:53

Short answer: lack of semantic information

Long answer

In a forum, the user naturally expects stuff to come from "unauthorised" third parties (any registered user, could be anyone really), not only from the webmaster (and authorised authors).

The user fully understands that messages do not represent the webmaster opinion, and are not "authorised" in any way by the owner of the domain. For any reasonable user, there is no strong particular expectation regarding the content of messages appearing in the web-page, or for images included in such messages (there is a weak expectation that scum is removed on a timely basis, but before it is removed it can be seen by anyone).

But a web-browser does not understand what a forum is. The https://example.com/ page is expected to be trusted to come from example.com and to securely (as in transport security) represent example.com web-master opinion, and any big enough insecure image (in particular IMG without an explicit size) could be used to show a big warning that

Your account is suspended. You must go to http://fakesite-example.com/ to confirm it. If you don't, your account may be permanently deleted.

rendered as an image.

Of course, in a forum message it would be taken as representing the post author opinion by the user, but the web-browser cannot know that.


Actually, tylerl, the browser does know what type of information a resource is intended to convey.

The obvious risk is that information is exposed in the request (once javascript is injected into the page, it's trivial to inject data into the URL without changing the functionality, e.g. img.src=img.src+'?session=1234'; ) and it can therefore be used for compromising the exchange.

Another risk is that the image may have value - in terms of copyright, confidentiality or perhaps as part of an authentication process.

  • I should also have added that, with the addition of canvas support in html5, content delivered as an image now contains machine readable data.
    – symcbean
    Commented Jul 13, 2012 at 8:43
  • Is any of that scheme dependent?
    – curiousguy
    Commented Jul 16, 2012 at 3:27
  • Eh? Yes, no. SSL is usually only available as an option on HTTP - you can't make JSON requests over FTP:, telnet:. Any data sent over an unencrypted protocol is by definition not encrypted.
    – symcbean
    Commented Jul 16, 2012 at 9:15
  • hold on though -- if I'm able to inject javascript into the page, I can do evil without triggering a mixed content warning. consider I create a NEW image, add it to the document with no display (or outside the page, whatever) and add the session ID or whatever other params/cookie values/etc I want. If the NEW image is loaded from a server I control with HTTPS and a valid cert, then there is no mixed-content, but I've still done evil. I also don't see how a mixed-content warning applies to copyright/confidentiality?
    – Kasapo
    Commented May 9, 2017 at 19:08

Another reason why warning about mixed content is a good idea is that a MITM can replace an "insecure" image with one that exploits an RCE (remote code execution) vulnerability in the user's browser.

Here's an example of such vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2017-2416 --basically you can serve a crafted image containing executable code and have that code executed on older versions of macOS and iOS.

So even though I believe that passive content is generally more secure than active one (but unfortunately I don't know any papers to back this "belief"), any content that can be arbitrarily replaced by a MITM is a potential security threat.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .