My organization utilizes Salesforce and Marketing Cloud. Very few people have access to MC, so I'm in the process of building MC hosted landing pages that will pull and display information such as marketing stats, pipeline stats, close rates, etc.

The purpose of using a landing page for this is so that I can give non-technical users access to an interface that graphs and displays relevant reports to them. (And saves me having to pull and Excel graph the info every x days).

Obviously, I don't want the general public to get access to these pages or data. The pages themselves will be marked as no-index no follow - but that doesn't fully stop the URL from potentially getting out into the open.

So, my next thought was to use the viewer's IP address against a list of approved ranges to decide whether or not to display data. Is this secure enough? What are some pitfalls?

By secure enough, I mean that I'm trying to guard against unknowing public access and competitive businesses that, most likely, would not assign anyone super technical to getting access to the page.

Please let me know if I can clarify anything further. Thanks!

  • Need more information, whitelist on webserver app? whitelist on firewall? whitelist of specific IP's or IP ranges? Jan 18, 2018 at 20:51
  • So basically, using an IP address as a form of authentication?
    – forest
    Jan 18, 2018 at 20:56
  • @CaffeineAddiction, My thought was to add my company's IP addresses to a whitelist stored in a data table in Marketing Cloud. Server Side code would be used to compare the client's IP to the approved list and then load data or load an error message.
    – user168825
    Jan 18, 2018 at 21:08
  • @forest, yes, that was my thought. I've asked over on Salesforce.SE about different ways to restrict access - but there really aren't any. Using an IP whitelist IMO is better than a text-field form that asks for some piece of data, but those are really the only two options that I can think of...(Hence the question on IP whitelist security and pitfalls)
    – user168825
    Jan 18, 2018 at 21:12
  • 1
    @Sparrow, I'm stuck using the tools I have, which means the page has the ability to execute AMPscript and Server Side JavaScript before serving the page...and that's about it. But, I think you're onto something. I can create the link library in their Salesforce view so that, whenever they go to the page, the latest token is included. I like this a lot - keeps it easy for the end user and I can automate the token renewal and placement in the URL. Answer-ize it?
    – user168825
    Jan 18, 2018 at 22:25

3 Answers 3


Depending on how much flexibility you have, you can consider adding any of these options to your IP address check:

  1. You can you create some random tokens that expire every few days and use them as part of the URL parameter. This is similar to what most web applications do for password reset; when they email the user a link that contains a URL with a random token that expires within a few days or hours.
  2. You might also consider implementing SSO (single sign on) for this application. This is going to be a big and complex task. By implementing SSO, you won't need to check the IP address anymore.
  3. Another option would be that you send a PIN to the users every day and have user to enter their PIN. The PIN should be random too. This is a very weak approach, but combined with the white listed IP address, you are at least adding another layer to your security.

First of all, make sure your Web site has all the necessary protection against typical XSS and CSRF threats, where a victim's browser, which sits on an IP address you've allowed to access the data, is tricked into revealing your data to a third-party.

Regarding IP ACL-based authentication in general, as long as it's only read access, you're probably fine with that. Nevertheless, it might be useful to know that under certain circumstances and given necessary preconditions, a motivated attacker can use BGP hijacking to impersonate your users for a relatively short period of time.

This method is somewhat easier to perform if an attacker is able to find out what source IP addresses are allowed to access the data; however, using methods similar to what have been discussed in this talk (video, slides, whitepaper), this requirement can be further lifted. (I'm the author of said whitepaper, so don't hesitate to ask for further clarification if you'd be willing to)

For most applications though, it's rather hypothetical, as it is unlikely that such a complex approach would be taken by an attacker, however, it heavily depends on how precious your data could be for a malicious person.

With respect to write access, IP whitelisting for TCP-based services in general should not be considered safe anymore, as a TCP connection can be successfully spoofed nowadays, given enough bandwidth and computational power on behalf of an attacker. However, using TLS is currently enough to mitigate this.

If only people from within your organization should ever be allowed to access the landing page, it might be a good idea to set up a proxy on the Intranet and to allow only Intranet addresses to access the data via that proxy. How the proxy authenticates on MC is more or less up to you. For an out-of-office access, a VPN could be set up, eliminating almost all the exposure to the general public (obviously except for browser-based attacks I've mentioned previously).


Security is about layers. IP whitelisting is good but if you whitelist Salesforce, what about someone with a Salesforce instance redirecting requests through Salesforce to you for example.

IP Whitelisting + Authentication requirements Well now an attacker needs to send requests from Salesforce and try to steal or bruteforce credentials

IP Whitelisting + Client Certificate authentication Well now an attacker needs to come in through Salesforce and steal a client certificate somehow

SSO by itself still allows someone to bruteforce an account to get a SSO token - if you are going to implement something like SSO include MFA if you really want to secure it.


You must log in to answer this question.