Form 2.0 prefill when embedding

Form 2.0 prefill when embedding

When embedding a form 2.0 on a web page, form prefill currently does not work. Let's make oit work 🙂
Level 10 - Community Moderator

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.

Level 10

Take a look at the comment that Justin Cooperman (Senior Product Manager) posted into this discussion thread: Forms 2.0 : embedded forms do not prefill ?

Here's a copy/paste:


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 just requires a very thorough review by our internal security team. I plan to work on this next year.


Marketo Employee

If you're embedding on a Marketo LP, pre-filling is No Biggie.

Why can't you just iFrame in a page with a pre-filled form?

form.vals({"Postal Code":"{{lead.Postal Code}}",

                        "Phone":"{{lead.Phone Number}}",


                          "First Name":"{{lead.First Name}}",

                        "Last Name":"{{lead.Last Name}}",

                          "Company":"{{company.Company Name}}",

                          "Email":"{{lead.Email Address}}",




Level 10 - Community Moderator

That's always been true, but that's undercutting the very compelling reasons for embedded forms to exist....

Level 10

Hi Mike,

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 ?


Level 10 - Community Moderator

I think we have to consider several different levels of -- shall we say -- potentially problematic (not always clearly malicious) uses of prefill:

  1. Malicious attempt to harvest data outside the browser based on a list of known emails
  2. Malicious attempt to harvest data within browser origin constraints by having the lead inadvertently participate by providing their email address
  3. 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)
  4. 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...

Marketo Employee

I just helped an implementation with this where we iFrame in a page with the form.  Prefill works like a charm.

Level 9

iFrame is definitely the way to go until embed prefill works.

Level 2

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.

Marketo Employee

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.