Prefill Gravity Form from Marketo Data

[Mx_Braze]

I've been tasked with something that's a bit out of my depth. Here's a quick rundown of the process I'm supposed to enact:

1. Person gets email with a link to fill out a Gravity Form on our own website

2. Marketo sends data about the person (including their email address and some other attributes) to the form
3. The form sees this info coming and hides any fields that are prefilled from the form
4. Person fills out any missing info and hits "Apply" button. Sees "Thanks for applying" message

In an ideal situation, Marketo will have all of the data needed by the form and upon clicking the email link, theyn will just see a "thanks for applying" message and be done with it. At first I thought, "I can just append the data to the URL generated when they click the link" but I'm definitely not going to do that with someone's email address. I searched around on here and keep seeing people talk about a solution on a page that no longer exists (http://developers.marketo.com/blog/external-page-prefill/). Of course I also saw a bunch of people comment on how that method wasn't secure, so that's probably why it's gone.

Does anyone know a secure method to accomplish this? I'm generally pretty good at reverse engineering things so if there's a tutorial that comes anywhere close to what I'm describing, I'll gladly try to work it out. I just can't find anything in the documentation that's anywhere close to what I'm trying to do.

[SanfordWhiteman]

Search for "SimpleDTO." That's my cross-domain Pre-Fill solution, works for any form (or just for personalization), trusted by dozens of sites.

You can make it as secure as you want — as secure as native pre-fill, i.e. only using mkt_tok, or slightly looser.

---

At first I thought, "I can just append the data to the URL generated when they click the link" but I'm definitely not going to do that with someone's email address.

---

FTR, most people’s (relative) concerns about this are vastly overblown. Any link that automatically fetches the person’s email address value is as insecure as appending the value itself.

That is, if https://click.example.com/1234 takes me to https://pages.example.com/somepage.html?mkt_tok=5678, and /somepage.html pre-fills my email address, there’s no material difference between that and sending https://pages.example.com/somepage.html?email=sandy@example.com&mkt_tok=5678. In both cases, if I manage to snatch the tracked URL, I have your email address.

Lots of energy is wasted worrying about “PII in GET” that just amounts to the same leak in the end, because the email address is revealed on the destination page without user intervention. (On the other hand, if you never fetch the email address or any other data, that’s a different story.)

[Mx_Braze]

I appreciate the insight on the matter. Unfortunately, my IT/Security team won't allow me to make use of a random extension on Github, which I suppose I understand. I'm working with someone internally on this and will post again if we come up with something.

[SanfordWhiteman]

“Random” isn’t quite right, given that it’s written by the moderator of this official community (who has also found security vulnerabilities with major form vendors).

But in any case, you have only 2 choices if you try to roll your own:

1. pass the data in the URL
2. copy the approach of SimpleDTO (cross-origin messaging with a Marketo LP)

For a counterexample, you cannot turn to the Marketo REST API without introducing a glaring DoS vulnerability (anyone can hit your LP and consume all daily API calls by passing junk lookup data). In contrast, (1) and (2) are not subject to API limits.

You could attempt to add frills to (1) like encrypting the data within Marketo using a preshared key — requiring bulk updates using the REST API or a webhook-compatible service, of course. Then you pass encrypted data in the URL and decrypt it on your back end before displaying it. This still means anyone who can steal a URL can steal the data. As noted, anytime you decrypt something without user participation the true security is questionable.

[SanfordWhiteman]

@Mx_Braze please return to your thread and check responses.