Is it advisable to use AMPscript as validation on a custom subscription center?

Question

I have built a custom subscription center using SSJS and AMPscript and I was wondering if, beyond the fact that it works, if it's up to security standards.

The center is just one cloud page which uses AMPscript if/else statements to load certain sections of the page based on a CloudPages() URL and user input on the form on the page. It shows the form on default, and when the submit button is pressed, after email validation, it loads a confirmation and redirect message on the same page, hiding the aforementioned form.

The form itself is basic. It asks for first + last name, email address, and then a bunch of check boxes for newsletters to sign up. I have IsEmailAddress() validating the email, and a RequestParameter() checking the email against the DE list. If the email doesn't exist, it prompts the user for a confirmation submit, and use an UpsertData() and DeleteData() to swap the emails in the DE and a InvokeUpdate() to update the subscriber status on the All Subscriber list. If the email does exist, the subscriber is prompted with our membership hotline for further assistance if required. It does not load information from the inputted email, only the one which was sent the original email.

I was just wondering if this is appropriate and safe for our organization, thank you!

Answer 1

Ask yourself these general questions:

• Is your form POSTing all data? Do not send any PII data in GET parameters unencrypted. (+ URLencode is not encryption. :) )

• Are you prefilling form fields with PII? This is a potential risk if your page looks up information from within your Marketing Cloud instance. Emails can be forwarded with no means of prevention. So if I send "my email" via forward somewhere, anyone else receiving the mail can see my data.

• Are you exposing client side logic including PII data? AMPScript is server-sided code. So that's good. SSJS obviously is as well.

• have you Backend validated everything? What data can be entered into your DB? In addition to isEmailAdress and the likes, you can use regexMatch() to backend-validate inputs before writing them anywhere. this also helps function of follow up processing, not only security.

• Can a "user" (exploiter) use your form to find out anything about who is in your DB without any form of authentication?

Your form seems to still be guilty about this last point, as it tells a user "call support" if the emailAddress entered is found. It's easy to find out which of your two form reactions says "this email is in my DB".

I could theoretically, say as a competitor, run "my" DB against "your" DB via the form and find out who is in both. To do whatever with that info. Double Opt In features are made to counter this, as 1) not everyone within "my" DB would confirm the DOI, 2a) if they did, they would see a thank you page 2b) they might complain at the form owner, alerting him 3) I, the exploiter, would never know anything about this.