Is it safe to store a user setting you don't want the user to ever modify as a user option?

Question

I have added some custom user options to the profile page on my site, and most are all OK for the user to modify themselves. These options live in their own section. The users have read access and are able to visit the backend and change some settings in their profiles.

There is another per-user option that I do not want the user to ever be able to modify directly. I have the code that creates that option group and section check if the user can edit other users' profiles. If they cannot, the section and the setting are not registered with WordPress (and thus not displayed on the profile page). Only someone with the proper permission can visit to the edit profile page, view, and change the setting via the backend.

Can a malicious user ever submit additional POST data with an otherwise valid profile update and set an option that wasn't registered on the page, but does exist in the database? How certain/solid is this protection? Are there any known problems with it?

Answer 1

You should (if available) submit the code you are working with, even if just a snippet, so we can assess your process in relation to your question.

The short answer however is YES, it is safe, so long as you,

• prevent input fields being displayed on user profile page for certain user roles
• prevent unauthorized users from saving user meta to the database

First:

If the input fields which pertain the user meta data are hidden from specific user roles on the user profile page then "attacker" would need to guess what the meta_key is for the field in which they wish to populate. Good luck with that!

Second to that:

If they were able to guess the meta_key in question, they'd then need to run functions pertaining to update_user_meta or add_user_meta. The only way they can do that is if,

• they can see the input fields
• you've failed to check for user capabilities via conditional statements.

...which then would allow the user to save or edit those user meta fields which should otherwise be hidden not added/rendered to the request on screen.

We'll assume that,

• you provide no other means for users to run arbitrary scripts of their own choosing anywhere else on your site

...which mitigates the risk of an attack happening in the first place.

A start would be to wrap functions related to adding or editing user meta data in the current_user_can function.

if ( current_user_can('edit_users') ) {
 
    //show input fields function

    //allow input fields to be updated function
}

This checks whether the current user can actually edit_users which by default is only available to Super Administrators and Administrators unless you've otherwise allowed this capability to another user role of your choosing.

This isn't the only check you may wish to make, but its certainly one of the more important ones to include for safety.