Restrict attributes editing from the client side

@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 c.io from your browser, you should see “failed attribute change” errors in c.io logs
• In general, update all profile data from your backend to c.io (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 c.io 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 c.io usage cost in terms of MAU.
  → @Customer.io @Jordan can you give your thoughts regarding this, as this looks serious enough to require a specific recommendation from c.io 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 c.io!

@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 @Customer.io . 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.