Prevent creating new identified users from the client side

  • 28 March 2024
  • 3 replies


I see that using the JavaScript SDK that requires to expose the site-id to the client, anyone can run this simple code

  id: 'fakeuser',
  email: ''


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.


3 replies

Userlevel 2

Hey @ariel,


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’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, 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 @Jordan,

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.


Userlevel 1

@Jordan i also strongly support @ariel ‘s input of adding a workspace setting which disallows new people to be created from the JavaScript source, while still allowing anonymous user tracking and merging with existing users as they log in

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?