Error: account unlock with HTTP access is forbidden

I run Geth in a Docker container and use

docker exec -it bootstrap geth --datadir=~/.ethereum/devchain attach

to exec the Geth console.

  • 2
    Same problem here, I think it is as a result of some geth update. Apr 9, 2019 at 11:07

4 Answers 4


Yes, this error is about some geth update. See more about it in this merged go-ethereum pull request.

Overall, to bypass this protection, If you want to enable unlocking accounts with unsecure http (security risk), you can use "--allow-insecure-unlock" option when starting geth local server like;

geth --ropsten --syncmode "fast" ***--allow-insecure-unlock*** --cache 1024 --rpc --rpcapi eth,net,web3,personal
  • 1
    Sorry, I am still confused where to append 'allow-insecure-unlock'?
    – Wayne
    Apr 9, 2019 at 16:54
  • 1
    In your case something like: docker exec -it bootstrap geth --datadir=~/.ethereum/devchain --allow-insecure-unlock attach
    – artyppl
    Apr 10, 2019 at 9:20
  • 2
    It still shows the Error: account unlock with HTTP access is forbidden, why?
    – Wayne
    Apr 10, 2019 at 15:10
  • 9
    try to add "--allow-insecure-unlock" option when you start/run the eth-node.
    – artyppl
    Apr 11, 2019 at 9:12
  • 1
    added it as the last parameter in commandline and it worked :) Aug 19, 2020 at 5:08

It looks like you have geth open with --rpc, enabling HTTP access. If you unlock the account, anybody who can access that node by HTTP can do anything they like with that account, such as moving all funds to a different address that only they have a key to, or otherwise mess with whatever you're trying to accomplish. There are bots scanning for these sorts of vulnerabilities all over and you might suffer from the security hole even if not specifically targeted. (Example report here).

The best solution is probably not to allow insecure unlocking of accounts, though the dangers are considerably less if a strong firewall prevents external HTTP access on the relevant ports. A better solution would be to think more carefully about why you think you need the account unlocked, and if there are ways to accomplish those goals other than unlocking and leaving the account wide open. Alternatively, you could do the unlock on another node on the same blockchain network which does not enable RPC/HTTP access.


I found a same issue when I tried to deploy a contract on a private chain with remix-ide using we3 provider. It seems that a node with RPC/HTTP access and an unlocked account is needed. Otherwise, An error occurred saying "Not possible to connect to the Web3 provider. Make sure the provider is running and a connection is open (via IPC or RPC)".

In this case, I first had geth open with --unlock, and then enabled RPC with admin.startRPC() function in the console attached. It works!


the latest quorum release inherits upstream behaviour whereby it disallows unlock via HTTP-RPC for security reasons. There is a command line flag --allow-insecure-unlock which can be passed when starting geth which will re-allow this.

This is described in the upstream geth command line options here: https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options

(Note that geth doesn't actually support HTTPS, so that HTTPS_QUORUM_ENDPOINT must actually be using HTTP, or I'm guessing it uses HTTPS to connect to a reverse proxy which then attaches to geth over the HTTP-RPC port.)

Your Answer

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

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