Restrict attributes editing from the client side

  • 31 March 2024
  • 4 replies


Is it possible to have read only attributes for people, or at least attributes that are editable only from the server side? I want to use the in-app messages and I see it requires exposing both the site-id and the id, so the user has all the information they need to overwrite for example their email attribute, and it may cause problematic situations like sending mails to users that have never registered to my app.

So I am looking for a way to restrict attributes editing from the client side users, is it possible?


Thank you.


4 replies

Userlevel 3

Hi @ariel 

I’m afraid we don't currently have a way to lock attributes like that from the UI side of things. I can see how that might be useful though, so I'm going to add your vote to our existing feature request for it to let our product team know it's important to everyone.

In the meantime, you'd have to control the updates from the server side of things on your end.

Userlevel 1

@ariel very valid question. I must admit that I never really thought about this so far, but it’s an important point to consider! So thanks for raising this!

A few additional thoughts:

  • Changing the email attribute is a special case, as email is an “identifier”. Depending on your workspace settings and what’s provided in the API call, email cannot be changed. Read more here. It will only be changed given that you provide the ID (user-id) and not just email as identifier in your Javascript source, and that you have set "cio_id
    or id" to enabled in your workspace settings. If this is not enabled, the Javascript source would have to provide the user’s cio_id in order to allow email changes. If you try to issue such modified “identify” tracking calls to from your browser, you should see “failed attribute change” errors in logs
  • In general, update all profile data from your backend to (as “identify” tracking call) and not include any user attributes in the frontend tracking other than e.g. ID of the user. If you do this at registration, but also at every login, it will overwrite the email again in the case you’re mentioning. And having only the ID in the frontend limits the variables that potential manipulators can see exposed in the frontend. Only track pageviews or events that only the frontend knows about with the Javascript Source
  • I more see the problem of adding new random users to your account by using your exposed site ID and cio write_key. So attackers could add millions of new users with their emails using the exposed info, which leads to spam and high usage cost in terms of MAU.
    → @Jordan can you give your thoughts regarding this, as this looks serious enough to require a specific recommendation from side! Thanks a lot!
    → I feel that adding a workspace setting which disallows adding new people via Javascript source would perhaps solve that. Anonymous users would still be tracked, but only merged with existing users once they log in (or create an account where the backend will then identify them and create the record via API)

Hope that helps. And hope we can continue this important discussion here with official input from!

Userlevel 1

p.s. I just noticed that there was a 2nd question about exactly this topic of adding fake new users from clientside. Sorry that I did not notice this earlier. By coincidence @ariel you are suggesting the same that should add a setting to disallow new people being added via JavaScript source.

@digitalisierungsprofi  Thank you for your detailed answer!

The root cause of both issues, here and in my second post, is the same: It turns out that exposing the site-id or the customer id is too risky, and those risks must be mitigated by . But in-app messages requires you exposing them (unless you are ready to do lots of programming by yourself).

About changing the email, currently you MUST DISABLE the email identifier if you expose your site-id, otherwise a malicious user can also corrupt other users data by guessing their emails!

Anyway the user can currently manipulate their own data from the client side, and that is the subject of this post. I think it must also be limited somehow, either by a workspace setting that prevents this, or by read only attributes.