Security problems with Preferences Center

Question

Hi guys,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?Regards,RaúlMessage was edited by: Raul Ocaña

Grégoire_Miche2 · Accepted Answer

Welcome to the club ...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. -Greg

SanfordWhiteman · Answer

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded