Since access permissions are (by default) set to proofOrSignature, an owner may attach arbitrary account balance updates beneath an AccountUpdate to the deployed smart contract which does not require proof authorization, e.g. a nop AccountUpdate or a receive AcccountUpdate.
Impact
The amount of trust placed in the token deployer is (by default) total. Signature access permissions are required for other signature-authorized permissions like upgrading, setting permissions, or setting the URI in the default smart contract permissions. While the owner is already a privileged actor by default, this is an important action they can perform which may be unexpected to users of the token.
Whenever someone upgrades a token contract to be “non-upgradeable,” users must check that the owner set access permissions to proof only.
Recommendation
Document this possibility clearly in the token contract, on the permissions documentation, and on the documentation of the “approve” function.
Consider changing the default behavior to upgrading/changing permissions via a check with the admin contract, and defaulting smart contract access permissions to proof-only.
As part of #99, we set the access permission on the token contract to proof. We also set setPermissions = impossible, and point out that users of the token should check those permissions.
Since access permissions are (by default) set to
proofOrSignature
, an owner may attach arbitrary account balance updates beneath anAccountUpdate
to the deployed smart contract which does not require proof authorization, e.g. a nopAccountUpdate
or a receiveAcccountUpdate
.Impact
access
permissions are required for other signature-authorized permissions like upgrading, setting permissions, or setting the URI in the default smart contract permissions. While the owner is already a privileged actor by default, this is an important action they can perform which may be unexpected to users of the token.access
permissions to proof only.Recommendation
Document this possibility clearly in the token contract, on the permissions documentation, and on the documentation of the “approve” function.
Consider changing the default behavior to upgrading/changing permissions via a check with the admin contract, and defaulting smart contract
access
permissions to proof-only.