1 of 1 people found this helpful
if you implement what's written in the article, it means you will have to do the REST API call from you web server. NEVER do it from the client side, you would expose yourself to pretty bad consequences (such as DOS on your Marketo API and ny type of misuse that people would make from your REST API credentials).
It's not just that. The whole approach is incredibly dangerous even when the API is called from the server, and IMO should never have been published. Merely proxying REST API calls in response to end user actions, but not performing any rate limiting, is still giving those users implicit control over a mission-critical part of your architecture.
We run into fallacies like this a lot in security, where for example somebody perceives that because an attacker doesn't have access to read the database credentials, they're somehow limited in what they can do. While it's true that not being able to copy and paste the credentials into for a later attack is good (same with the Marketo situation), if a webserver lets me send whatever SQL queries I want, it doesn't matter that I don't know the username + password that are used to log me in.