Hello,
I see that using the JavaScript SDK that requires to expose the site-id to the client, anyone can run this simple code
_cio.identify({
id: 'fakeuser',
email: 'fakeuser@gmail.com'
});
and that user it is actually created in the People collection. So a malicious user can run this million times with different ids and to spam our people collection which contains real identified users.
Is there a way to prevent this?
Thank you.
Hey
As is the case with any frontend library, misuse like what you’re saying is certainly a possibility.
An immediate solution, requiring dev resources:
For total control over these things, we recommend using our backend integrations wherein you can validate all identify/event requests before sending them to CIO.
If you want to utilize Customer.io’s in-app messaging feature on your web app, at this time there isn’t any way to prevent a person from using the SITE_ID to send identify calls and events via our Track API JavaScript snippet. So if you’re looking for a way to send in-app messages, you would need to have your own messaging feature that you can trigger via Webhook Actions in Customer.io, so that all requests flow through your backend service(s) wherein you can validate their authenticity.
One potential solution, using the CDP and Destination Action filters:
If you’re using our CDP, there is one method that you can look into using right now, which is to specify that requests with a specific key-value pairing are not sent to your CIO Destination — using Filters. (Of course, a person could study the network traffic and possibly decode what that key value pairing is, but it would be a bit of guessing on their end since they couldn’t see what your CDP configuration is) This solution only works if you’re not also trying to send in-app messages to your web app. If you do that, a person could view the web apps source code or network requests going out and reverse engineer a way to send page, identify, and event Track API calls.
I’ve added your upvote to a feature request to add permission scoping for all API credentials. This might enable creative methods of preventing misuse, like having one set of permissions for API credentials used on your backend services / edge functions, and another set of permissions to use on your application’s frontend code.
Hi
thank you for your reply.
I think the solution should be a setting in the workspace level, whether is it possible to create new people directly from the client side or not. I can think of some legitimate use cases, like landing pages of small businesses, that are not attractive for malicious users, so the benefit for the user is greater than the risk. But for a big application with lots of real identified people it is just too risky. And relying on the server side for the purpose of transferring many tracking events requires a fast dedicated infrastructure, for not slowing down the client side.
Thank you.
I think the solution should be a setting in the workspace level, whether is it possible to create new people directly from the client side or not
What do you think about that?
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.