We almost forgot about this, but a user can, by default modify his profile however he wishes with client side methods.
Meteor.users.update(Meteor.userId(), {$set: {'profile': {}});
Just a friendly warning, do this:
Meteor.users.deny({
update() { return true; }
})
We encovered this prior to a big release, it can be easily missed, even if Meteor warns us not to use “profile” and it is like this because of historical reasons.
Right, because Meteor.users.allow is already used by core so only the deny option is present.
We do mention this in the guide with a similar code snippet: https://guide.meteor.com/accounts.html#dont-use-profile
I believe the way this section was added at the very bottom of the Security page allows it to be overlooked very easily.
I went through the Security page before going live with our app and actually did not notice this on there. I looked again just now and do see it on the checklist at the very bottom, just doesn’t seem very obvious there. At least compared to the rest of the security page.
Do you mind sending a PR to make it more obvious?
Any details on what versions this applies to?
All of them? May be?
All of them indeed. 
This is why I wanted to put it out there.
It is obvious already, but it’s just easy to miss it for some reason… “profile” is like a the most intuitive variable to store some info about a user 
Agreed - perhaps we should remove this feature entirely in whatever next release makes sense, and somehow print a warning when people try to write to that field.
That is a very good idea, and I believe it’s the way to go.
There’s an issue about it with very little discussion:
Let’s bring it back to life!
Is there ny other ones we should know about? Like old ones or new ones? Thanks
Everything we know about is listed in the security article in the Meteor Guide: https://guide.meteor.com/security.html
However I’ll be the first to admit that it’s a lot to read so it’s easy to miss things.
Would it be appropriate to user profile:{} as an additional store for complex or extensive application state data? Would doing so with schemas attached to the field prevent security concerns?
Personally I’d just stay away from it entirely.
Maybe it’s time to disable it by default but provide debug messages for people who use it?
console.log("Profile.update() has been disabled by default, but you can re-enable it with Meteor.allow()");
I still use the profile object today, but always disable updates from the client. So if I want to update something say “isUserAdmin”, I do that with a method on the server called with the right permissions from the client using Alanning Roles package. Just make sure you disable client updates on the profile object. Disabling it all together as suggested is not entirely a bad idea.