A client recently asked if it is possible to embed a secure (HTTPS) donation form on their site with an IFRAME without using HTTPS on their site. My answer was it depends but it’s not a good idea.

It is possible to have an IFRAME on an insecure page (loaded over HTTP) load content from a site over HTTPS. And while a form loaded from a secure (HTTPS) host will post over an encrypted connection, it is not a secure practice.

A secure form should protect against clickjacking. The main defense against clickjacking is to set the X-Frame-Options response headers to disallow loading content within a frame. See https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options for details on setting the X-Frame-Options header and https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet for more information on defending against clickjacking.

But even if clickjacking was not an issue, adding a donation form (or any secure form) as an IFRAME on an insecure page is not a good idea because it exposes the user to a man-in-the-middle attack. A man-in-the-middle attack is an attack in which a hacker gets in the middle of the communication between the browser and server so that they can eavesdrop and/or alter the content. As security expert Troy Hunt explains, it is easy to launch a man-in-the-middle attack with an inexpensive device called WiFi Pineapple. Once a hacker has established a man-in-the-middle connection, they could quite easily replace the IFRAME src with their own and thus capture credit card info and other sensitive data. For this reason, all forms that submit sensitive information, including all login forms, should be on pages that are served over HTTPS.

One more security tip: you should be careful of what external javascript files get loaded. When you add an external script, you are essentially trusting the host that their systems are secure and they are serving benign javascript. One defense to help ensure that your site is using scripts from trusted hosts is to use the Content-Security-Policy header to define approved sources for resources the browser can load for your site. See Scott Helme’s introduction to Content Security Policy for more details.