I'm building an ERC20 smart contract which will be accessed via node.js with web3 library. I see that web3.eth.Contract has the send function, which takes the parameter from, which is being mapped to the msg.sender in the smart contract. As far as I understand (and my debugging supports that), I can change the from field to just about any address, and by that bypass the business logic of the contract, e.g

token.methods.method_only_owner_can_activate(<some_data>).send({ from: <contract_owner_address>, <gas> });

or even set the owner:

token.methods.setOwner(<my_not_owner_address>).send({ from: <contract_owner_address>, <gas> });

since the address should be public, any user can create a process which mimics this behaveiour and bypasses my security logic.

There are other methods which do sign a transaction with the private key, but the fact that the send method is open for bypassing the business logic, seems like a big security concern.

As I missing something?

  • 1
    You are missing the fact that your contract_owner_address is unlocked on the Ethereum node that you are connected to. Either you are (unknowingly) unlocking it in your code, or the node is (unknowingly) unlocking it for you. Sep 2, 2018 at 17:38

3 Answers 3


Any transaction to an actual Ethereum blockchain needs to be signed with a private key.

For the above code to work (just supplying a from address), the node you're connected to must be doing the signing for you. As long as the from address is "unlocked" in that node (the default under a test network like ganache or done explicitly using a normal node like geth or Parity), it's able to sign the transaction with that key and send it.

In a real-world situation, users of your app wouldn't be connected to a node that had your private key, so this is not a concern.


The web3 library creates a transaction that needs to be signed by the account specified in from. It is signed either by talking to a local node which has the private key to that account and currently has it unlocked, or by a piece of software like Metamask which controls that private key and only signs the transaction if the user confirms.

It is not possible to send a valid (signed) transaction without the private key of the account in the from field.


The msg.sender property can't be faked - at least to the extent that someone can't create a transaction with a msg.sender which isn't an address they own.

Whatever security measures you have in your contract, you can rely on the fact that the msg.sender address is the person making the transaction.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.