Secure Your Web and Landing Pages
After completing this unit, you’ll be able to:
- Use SSL encryption for page interactions.
- Create form security methods to prevent malicious submissions.
Protect Your Pages
We talked about the security features and encryption keys built into Marketing Cloud earlier in this module. And as a security-conscious developer, you’re probably eager to secure your web and landing pages in Marketing Cloud, too. After all, what’s the point of all this security if you let anybody (or any bot) in the door? Here’s how to lock down your pages.
Use SSL Certificates
Marketing Cloud handles more than just messages—web pages allow subscribers to submit information, subscribe to communications, or view messages outside of their email client. To ensure the safest experience, we recommend using SSL certificates to secure web-based communications. These certificates can secure:
- CloudPage URLs
- Landing pages in your account
- Links included in email messages from Email Studio
- Portfolio content
Plus, SSL certificates add an encryption layer to web traffic and help prevent external parties from intercepting sensitive information. Whew! That’s a relief.
Need a certificate? Well, you can purchase your own certificates or you can allow Marketing Cloud to manage those purchases for you. If your certificates are purchased through Marketing Cloud, you can use them to secure both pages and content. Plus, Marketing Cloud manages and renews the certificates with no additional cost. If you purchase your own certificates, you can only use your certificates to secure pages (not images).
Manage Form Submissions
When you use CloudPages or API integrations to capture subscriber information, it’s important that you handle it with trust and security in mind. We’re here to help. Check out these tips to help you secure your form data. (And remember, these aren’t the only security factors you should consider, but they’re a good place to start in Marketing Cloud.)
- If you include query strings in your pages, don’t pass SubscriberID, SubscriberKey, or ContactKey values in the clear. Also, use encryption and not Base64 or StringtoHex encoding to pass values from fields. Encoding can be easily decoded, as opposed to attempting decryption.
- Any processing and validation of fields should occur on the server side. We also recommend using two or more query string parameters to verify that the same subscriber is interacting with the page before presenting any data.
- Any application pages you create should require authentication. We recommend using the AMPscript MicrositeURL function to encrypt query string parameters.
- Any non-authenticated or non-application public landing pages should include a global IF/THEN clause that checks for empty required parameters. This step prevents any processing when somebody tries to access the page directly, instead of through your assigned flow.
Example: Enable Security Headers for a Web Page
<script runat=server> Platform.Response.SetResponseHeader("Strict-Transport-Security","max-age=200"); Platform.Response.SetResponseHeader("X-XSS-Protection","1; mode=block"); Platform.Response.SetResponseHeader("X-Frame-Options","Deny"); Platform.Response.SetResponseHeader("X-Content-Type-Options","nosniff"); Platform.Response.SetResponseHeader("Referrer-Policy","strict-origin-when-cross-origin"); Platform.Response.SetResponseHeader("Content-Security-Policy","default-src 'self'"); </script>
This example helps prevent common web form issues, such as cross-site scripting or SQL injections.
Ready to go further? The next unit tackles our top data security recommendations and best practices.