Following up from IP Spoofing .
Here is the scenario:
1. We have a Marketo landing page with a Marketo form.
2. API calls are made to an external server to pre fill the form using an api key.
3. After user interaction and updates, the Marketo form is submitted.
4. API calls are made to the same external server to then update the user info.
Now that you've removed the security requirements expressed in your other post, this is easily realized.
The Forms 2.0 JS API has robust support for setting values originating elsewhere ( / ) and an event model for running tasks just before or just after the form is submitted ( / ).
That the same service is used to GET starting values and to POST updates isn't actually important. They might as well be two different services. The GET is like using a lead enrichment service, or an email pre-validation service. The POST is like cross-posting form values to Google Analytics or GTM. Both see tons of use in the wild, and lots of demo JS is available here on the Community.
But to reiterate, you aren't securing that service against use outside of the Marketo page. It's impossible to do so. If you use strict CORS Access-Control-Allow-Origin: validation on your server -- which I wholly recommend -- that only means someone can't scrape your code and call your service from another public page. It doesn't mean they can't spoof the HTTP headers, or other components of the payload, from their own local system.
Consider a service locked down to origin pages.example.com, where you own the domain example.com -- so no one else can put up a public site at pages.example.com. That means nothing to an attacker, though. They can send the Origin: pages.example.com from anywhere. They can even put up a website on their local machine that answers as pages.example.com if they feel like it -- trivial HOSTS file/host header stuff.
So overall, all you're talking about is setting values and then posting them to your external service (I recommend, as otherwise a Marketo form post that fails due to network issues will have a false record in your external service, although it could be argued that having the record in your external service is more important -- it's up to you how to order the calls).
Thank you Sanford.
Since using Forms 2.0 JS still doesn't remove the security issue, I guess we cannot use it for this scenario.
Yeah, you should've restated the security part in this post... otherwise it's assumed to not be a requirement anymore! (Though I actually thought you'd left it out, that's why I commented on it again.)
You cannot have an unauthenticated (non-password-protected, non-IP-restricted) web page that automatically (without any participation from the viewer) connects to a remote web service in a way that cannot be simulated by a malicious attacker.
We've just thought of another potential solution. If we host the landing page on an external page, i think we can secure the client key as well get all of our functionality.
The only issue I see is the marketo form pre fill on external landing pages. Your thoughts?
If we host the landing page on an external page, i think we can secure the client key as well get all of our functionality.
How? If you need to make an unauthenticated connection to the external service, that's still what you're doing. If hide a "secret" key behind another key or automatic auth mechanism, that just means the outer key takes the place of the inner key. It's no more secure.