Recently we implemented the preferences center, where you can enter and subscribe, edit your settings or unsubscribe. The problem here is that you can put any email for this without any validation, plus the use of cookies, if you fill a form (unsubscribe one) with other person email and go to the edit settings, it will recognize that email as yours and will bring your peresonal data.

So one step that I see here is to hide those options so you can only enter by link form email, plus this link will pre-populate the email in the edit setting form.

How do you guys manage your Preferences Center to avoid this kind of issues?

I have been keeping saying this to my customers for months and no one is listening

The way we handle it is making sure that the preference center can only be accessed from an email link. It's not 100% perfect because of the forwards (in which case it's your lead's problem, though), but it's a first level. The way we do this is with some JS that controls that there isa mkt_tok in the inbound URL and that it's not fake (it generates an email). If this is not the case, the page redirects with a simple, cookie-less identification LP with a form where one can enter his email are receive a new link to the preference center.

The second level of security is to make the email field read-only in the preference center. There are some additional buttons to access the identification LP. There is also another button to access a "change email" LP that is also controlled with a series of emails.

And the third level is to have the preferences validated with a last email.

In your solution what will happen if a user submits the form that has the email only, but opens it from another PC? This new location won't have the cookies because it didn't do any form submit, so once the Preferences page loads (with email field as read-only), will it set the email address or it won't recognize it?

In my solution, whether the cookie exists or not does not matter. Only the mkt_Tok from the email matters. If the person accesses the page without coming from an email, he will be redirected to the identification page.

Raul, like Greg says, this is how Marketo Forms always work (whether labeled as "Preference Center" or regular forms). Since leads do not have a password, there is no way to authenticate them other than via email.

Removing the Email field -- so a mkt_tok-enized link is seemingly required for Pre-Fill -- merely obscures the functionality. It doesn't actually disable it, as you can still add a hidden Email field to the form post if you're malicious, and nothing can fully protect against that vector. (If you remove Email completely, also consider the legal angle: if you don't allow someone to enter another email address, then you're effectively stopping people from unsubscribing if they don't have an email on hand, which may not be legal -- talk your counsel on this.)

Unfortunately, there are multiple interests that are in conflict here.

On one hand, you want to allow people to manage their preferences from anywhere, regardless of whether they just received an email or not and regardless of whether they know a special self-management password. When used non-maliciously, this affords them the expected control over their marketing settings and is better for the relationship.

On another hand, you want to prevent the system from being abused by malicious actors. So you may wish to generate a new outbound email before letting somebody update their preferences. However, this [a] doesn't stop malicious actors from doing their thing and [b] increases friction, so may cause legit actors to accuse you of purposely making opt-out more difficult.

On yet another hand, there's the temptation to distribute passcodes via email and then validate them via an API-based process, not via standard forms. But, as above, this [a] doesn't disable forms from being used, [b] opens you up to a denial of service that may be worse than the original disease, and [c] is additional friction, though at least if they keep the passcode on hand they won't have to wait for an email.

Marketo will automatically add the Mkt_tok parameter as soon as you make the linjk traceable in the email. It does not need more. From the mkt_tok, Marketo will be able to identifiy the person and retrieve the data from the database without any cookie.

I didn't know about that link option. So in the JS validation for the mkt_tok, how do you check that is not fake, I mean I can check for the mkt_tok param and its value, but how do you tell that is a valid token instead of random characters?

We remove the cookie on page entry on the PC page, before the munchkin is ran. No data can be extracted from the database if the Mkt_tok is not present

If no Mkt_tok is present in the URL, we redirect to an identification page on page entry. That identification page is a no traced page with a form on which the only field is the email address. The visitor enters his email address and receives an email with a link to the PC page (with an Mkt_tok in it).

After the page is entered and the form is loaded, we check whether an email address has been retrieved from the Mkt_tok. If not, we redirect to the identification page

and we look the email field so that the person cannot change the email address (although a hacked could easily override this one)

In fact, we rely on how Marketo has encrypted the Mtk_tok to identify the person.

It does not cover the case of email forwarding, though. we have not found a way to cover this case. Hoping people will not forward emails to people they do not know (This is wishful thinking, obviously but it should not happen so often).

We remove the cookie on page entry on the PC page, before the munchkin is ran. No data can be extracted from the database if the Mkt_tok is not present

That's not exactly so. You have to remove the cookie and refresh the page without the cookie in order for the database record to not be loaded. The cookie has already been transmitted to Marketo during the HTTP request, and the Pre-Fill block injected into the HTML, by the time the page is drawn into the browser. Deleting the cookie at that point after the page is drawn doesn't make the Pre-Fill info go away.

We all feel your pain Preferences Centers are generally discussed as easy to setup but once you start digging in there is a lot to take into account and consider even without all of the new GDPR requirements. I complete agree with Stanford and Grégoire both helped with questions as I was going through this process, one thing we did was split out our Preferences Center into different functional areas that all work together.

The public subscription page, accessible on our website. The only trick we used here was to clear the cookie value on the form submission so that data is entered without being tied to an existing cookie ID. This is only able to add to new and update existing subscription, not remove any details. This uses a double opt-in, so unless you confirm your selection by clicking a link in the confirmation email everything changes back after 24 hours.

Manage your subscriptions page, only accessible from an email link. This clears any cookies before being loaded and uses only the data provided through the Marketo URL string to pre-populate contact details and existing subscriptions. This can both add and remove contact details and subscriptions. This also uses a double opt-in for any new subscription added.

Unsubscribe page, again only accessible from an email link. This also clears any cookies before being loaded and uses only the data provided through the Marketo URL string to pre-populate contact details and existing subscriptions. This can remove individual newsletter subscription or all newsletter subscriptions. No confirmation needed, but you are only able to unsubscribe the person that the email was sent to, that you clicked over from.

...and because we have a number of different business units each with there own version of the above pages we also have a "Global Unsubscribe" page, only accessible from the individual unsubscribe page that removes you from everything across the whole organization. This also only uses the Marketo URL string to pre-populate contact details. which means you are only able to unsubscribe the person that the email was sent to, that you clicked over from.

We use Mkt_tok URL parameter that is added by Marketo to links in emails. this parameter contains an encrypted unique identifier of the email addressee. Therefore, when the person clicks the email the LP get that information and identifies the person and retrieves the data from the database. This overrides the munchkin cookie that might exist on the browser.

I asked you that because I previsoly sunimted a form with someone else email, then sent a samle email to myself and when I clicked in the link, it had the mkt_tok but the prepopulated email wasn't the one related to the email but the last submited form. I think it might be a problmen with the email since it was just a sample not a real one...

How are you injecting Javascript to the form? I would like to prevent the access using JS and allowing only from email's link.

Note you can't actually prevent people from posting the form using arbitrary data, as I mentioned above. Protection you add via JS isn't really protection at all -- except from people who are technically malicious, yet completely technically unskilled. Not a very large cohort.

This is not to say it won't help higher-ups feel better, just like JS-based field validation, but it doesn't quite rise to the level of "security."