3 added 357 characters in body
source | link

Since the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example. Here is another example showing developers how to bypass this cross-domain security by embedding iframes of the main page within the iframe itself, so it's a hack which may not last for long as browsers get updated over time and fix these gaps.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

Since the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

Since the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example. Here is another example showing developers how to bypass this cross-domain security by embedding iframes of the main page within the iframe itself, so it's a hack which may not last for long as browsers get updated over time and fix these gaps.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

2 deleted 7 characters in body
source | link

I'm assumingSince the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

I'm assuming the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

Since the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.

1
source | link

I'm assuming the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.

Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage API call. In this cross-domain scenario, this only works if the document in the iframe accepts and responds to these message based queries from the main page. See this example.

The only issue I see here is that if any data is exchanged between the main HTTP page (unsecured) and the HTTPS secured payment page, then how sensitive is it and how well is it protected when crossing over to the unsecured HTTP domain.

But again, this kind of a concern is valid anywhere one web-app is passing user session/transaction to another web-app irrespective of whether iframes are involved or not. As end-users we don't know the type of communication going on behind the scenes between different service providers when completing a transaction. These are the kind of checks that PCI-DSS and others are supposed to validate.

I suggest you could trust them if both servers belonging to the HTTP and HTTPS pages belong to the same streaming service company.