[matthewarkin]

Historically, the thought has been that the iframe and a redirect could both be treated as SAQ A (the easiest form of compliance), was because if you changed the iframe that was displayed or the page the customer was linked to it would be extremely difficult to steal customer information in a silent way.

So if a merchant links to paypal.com/merchant, and I inject js to change it to paypal.com/matthewarkin. The merchant would immediately know something was wrong because they are no longer receiving money. The issue with how Stripe, Braintree, and others have implemented their javascript and iframe implementations is that is pretty easy to replace the iframe with a malicious url (paypal.com/matthewarkin) but still allow the merchant to receive their funds.

A simple fix for this would be the api keys used to instantiate the iframe only be usable from the iframe and could not be used to call the create token api directly.

[jtdowney]

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for merchants to use technologies like Content Security Policy and leverage as much of the browser security model as possible.

[matthewarkin]

I think more awesome, was the hosted fields you just launched, so that I can have a custom, stylized form where each credit card input is its own iframe.

https://www.braintreepayments.com/features/hosted-fields

[jtdowney]

I agree! I submitted it as separate item because this conversation was about rewriting iframes. Although hosted fields doesn't directly address the rewriting for now, we're looking at it closely.