SpecificUsersAuthorizationStrategy does an authentication check during newInstance, used by form binding. But this is trivially bypassed. I created two users (with Mock Security Realm): admin with ADMINISTER, and devel with Item.* permissions (also granting Computer.BUILD to everyone). As devel I created a job using this strategy and running as myself. Then I got its config.xml, replaced the text devel with admin, and used

curl -i -u devel:devel -d @config.xml -H '.crumb: ...' 'http://localhost:8080/jenkins/job/run%20as%20devel/config.xml'

When next run, it was run as admin, bypassing the intent of the security restriction.

Not sure what to recommend as the fix. Storing the strategy as a JobProperty makes it inherently rather vulnerable to this kind of attack. The only general way to intercept uploadByXml and friends from a savable component is to let the user upload and save whatever XML they want, but use readResolve to check the authentication in effect at the time of the upload (will be SYSTEM if this is just being reloaded from disk), and to retroactively reject configurations being uploaded by an unauthorized user. You can study what the Script Security plugin does; look at SecureGroovyScript and its calls to ScriptApproval.configuring and .using. For a job property in particular you may be able to use a simpler solution by overriding setOwner.

(In this case you do want to let regular users update other parts of config.xml using REST or CLI, so long as !isAuthenticateionRequired(...) [sic] I suppose.)