I'm talking about the DoS risk aspect in addition to the PII leakage aspect. With 10,000 API calls per day shared among all your integrations, you're taking a tremendous risk by allowing individual web actions to take up one API call each. A malicious individual with just a simple cable connection can quench all your calls in a couple of hours, crippling all the other connectors to Marketo (and of course cutting off the prefill functionality as well). The daily API limit is just too low for this to be advisable IMO.
My method's completely client-side and thus has no API issues. My bad for not publishing the full docs on it yet. I've leaned to toward walking people through a demo so I could show them what's going on at every level. Right now, I'm on jury duty so I can't ramp up my blogging! But I promise it's on the agenda.
Here is the product team's official stance on this:
For pre-fill to work on embedded forms, it requires a publicly accessible API that retrieves lead information, which can include personally identifiable information such as email addresses, mailing addresses, names, and phone numbers. For us to make enable pre-fill on embedded forms in a responsible manner, we need to make certain that the API is created in such a way that it’s acceptably protected from brute force attacks that could allow an attacker to retrieve information about all leads by guessing Marketo cookie values, as well as making certain that the API doesn’t expose leads to XSS (cross-site script) attacks that could be used by an attacker to steal a lead’s info when they visit the attacker’s site. These issues doesn't exist when the form is on a Marketo landing page because we process the content of the page on our servers and there is no API exposed publicly.
This is 100% on our roadmap and we know how much customers would like this...it just requires a very thorough review by our internal security team. I plan to work on this next year.
In fact, the point is all about how can we control the form prefil is only done on a site that we do control. I suppose that the way it's implemented on the Marketo Landing Pages enforces that control. So what we just need to do is to implement a similar control on our web sites.
Could'nt Marketo provide us with a key or similar mention that we would set on the DNS and that would match only with a given domain or given IP address and which would authorize the prefill of the form ?
I think we have to consider several different levels of -- shall we say -- potentially problematic (not always clearly malicious) uses of prefill:
Malicious attempt to harvest data outside the browser based on a list of known emails
Malicious attempt to harvest data within browser origin constraints by having the lead inadvertently participate by providing their email address
Providing lead data to a 3rd-party website with the opt-in consent of the Marketo instance owner (domain origin restriction stored in Marketo) but without the consent of the domain owner (interpreted as the controller of the domain's DNS)
Providing lead data to a 3rd-party website with the opt-in consent of the Marketo owner and of the DNS owner, but without the consent of the website operator
Vector [1] already exists but is impossible to eliminate; it can only be rate-limited.
Eliminating [2] by requiring opt-in via known origins added in the Marketo UI, IMO, is a must-have.
Requiring opt-in via DNS would be a great addition, though combined with a long TTL this method becomes hard to revoke and it's relatively toothless if it's only at setup time. I would be happiest if something like the Munchkin API "signed request" mechanism were required for 3rd-party prefill. This would allow for opt-in all around so no one is surprised. In fact the signed request mechanism is what I've used in my own prefill solution...
As stupid as this is going to sound, thank you so freaking much for pointing that out. For some reason it didn't connect in my head that if I'm coding my own form that's going to sit on a Marketo page, I can pre-pop the values on the input tags using tokens.
Still +1 on pre-filling embedded forms. Eloqua does it using Web Data Lookups. It takes a lot of development work to figure out how since the only documentation on it is community posted, but it is possible without compromising the security of the data being passed.
Just remember that, if your form uses conditional visibility, you have to pre-pop in that order. For example, if you have State visibility rules based on Country, you have to pre-pop Country higher in the list than State.
.png)