Re: Secure iFrames

From a high-level, your design should start with the HTTP-served index.html page that redirects to an HTTPS-served index2.html that calls the remote HTTPS-served iFrame-embedded page(s). There are details that will be specific to your implementation, like protocol restrictions on index (HTTP-only) and index2 (HTTPS-only) files, and so forth that I won't go into. But for the sake of old-school simplicity, that's the model I recommend and use. 


> On Nov 3, 2014, at 05:02, NightShade <[email protected]> wrote:
> 
> Was hoping to get some feedback on what everyone feels are best practices around securing iFrames.  I've seen a lot of payment platforms moving in this direction (ie. Gumroad, Stripe, Memberful) yet with little documentation around "here is the best way to secure the iFrame our JavaScript generates".
> 
> The best documentation I've seen so far recommends an HTTPS webpage with the each link pointing to an HTTPS link as well.  This way when you click the link to load a modal / JS for the payment solution it is "supposedly" done over HTTPS even though the browser won't present a padlock (assuming the hosting page is HTTP).  The other example I've seen is a simple HTTP page that contains an HTTP link which in turns opens a secure iFrame....which is probably not a good idea since you are mixing secure and non-secure content.
> 
> Thoughts?
> 
> 
> 
> This list is sponsored by Cenzic
> --------------------------------------
> Let Us Hack You. Before Hackers Do!
> It's Finally Here - The Cenzic Website HealthCheck. FREE.
> Request Yours Now! http://www.cenzic.com/2009HClaunch_Securityfocus
> --------------------------------------
> 



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now! 
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------