Cloud Page Header Security


, ,

I recently read the Marketing Cloud Security module on Trailhead and found the Secure Your Web and Landing Pages unit to be extremely interesting, however it glossed over the reason and function of the Example Headers that are recommended.

As the defined role gap between IT and Marketing is closing quickly, I thought this content needs to be given the attention it deserves from a non-IT perspective.

Website Headers and why you should care

Response headers are used to give a more detailed context of the response provided by a server. To critically over simplify this: When you hit SEARCH on Google.com your request is sent to Google to process – the response is then sent back and interpreted by your browser where is it rendered accordingly. If you are using Chrome, you can open the DevTools to see this in action: Instructions here.

With the example above, the response from Google contains a number of headers that instruct your browser what to do, for example:

content-encoding: br
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000
  • content-encoding: The response is compressed, and your browser needs to know which encodings were used by the server so it can decode the message.
  • content-type: The type of content contained in the response so that your browser knows how to render it.
  • strict-transport-security: This forces the browser to use the more secure HTTPS for communicating with the server, and sets a duration (in seconds) for this to be upheld.

So Headers are important. Why does Salesforce recommend we use these 6 on our pages?

The 6 headers outlined by Salesforce in their Landing Pages Security Best Practices provide an additional layer of security to prevent malicious actors from accessing your Cloud Page in ways that may hurt your business. Each of these 6 headers provide explicit instructions about how your Cloud Page can be accessed. Lets cover these in detail:

<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>

Strict-Transport-Security:
As above, this Header ensure all communication from a browser is sent over HTTPS. Without going into detail, HTTPS will protect your user’s data as it is sent to and from your Cloud Page. You really want to be using HTTPS if you are asking your subscribers to enter any form of personal information on your Cloud Page.
Note: SSL certificates are required to be installed by Salesforce Support and at the time of writing have an annual fee of ~$450 USD each. Adding this header without have an SSL installed on the appropriate Marketing Cloud Subdomain will result in the page request being blocked.

X-XSS-Protection:
XSS stands for Cross Site Scripting, and is a form of attach where a malicious actor injects scripts onto your page to make it perform differently.
This is a common header and most browsers support this by default. The “1; mode=block” value indicates that the header is active, and to block the page from rendering if a XSS attack is detected.

X-Frame-Options:
This header prevents your page from being loaded into a frame/iframe on another website.
The “Deny” value prevents any site from referencing you page in an iframe, however you can also use the “SameOrigin” or “Allow-From” values to specify trusted exceptions. You should always use this header unless you have an explicit plan for the page to be used in an iframe.

X-Content-Type-Options:
Content-Type sniffing is where an attacker can exploit a security vulnerability to interpret metadata from your site and possibly execute functions that the site was not built to expect. Forcing such errors can expose sensitive code or customer data.
Using the “nosniff” parameter tells the browser that the content-type is defined and not to be queried further.

Referrer-Policy:
The Referrer Policy controls how much referrer (origin site) information is sent in the request (destination site).
The “strict-origin-when-cross-origin” parameter will enforce HTTPS policy and only send the Full Referrer URL when the request comes from the same Origin. Cross-Origin requests will only see the base URL.

Content-Security-Policy:
This header acts as an additional layer of protection against Cross Site Scripting and other attacks.
The value recommended by Salesforce for this header is “default-src ‘self'”. This will force the browser to only load content that is served from the same place as the page with this header. This may cause problems with externally references images and CDN hosted JS libraries such as jQuery, so check the assets used on your page before enabling this one.

More ways to keep you Pages & Data safe

Cloud Pages are extremely versatile and powerful feature of Salesforce Marketing Cloud – however if used incorrectly can they can open up numerous serious security risks to your business and customers. Check with your company’s WebAdmin before enabling these headers and ask the Marketing Cloud community on Stack Exchange for help if you run into problems.

, ,

Comments are closed.