BITCOIN MAINNETLive explorer status
NO ONE IN CHARGE

Keep Bitcoin Core RPC private

Learn why Bitcoin Core RPC is a privileged control interface, how it differs from public explorer APIs, and what authentication does and does not protect.

RPC is an administration interface

Bitcoin Core's JSON-RPC interface lets other software ask questions and perform operations. Some calls read public chain data. Others can change node behavior or interact with loaded wallets. Treat access as a powerful capability, not as harmless access to a block explorer.

The exact consequences depend on the methods available, wallet configuration and version. A watch-only wallet reduces spending capability, but it does not make every administrative operation or metadata disclosure safe.

Public explorer requests should cross a narrow boundaryBrowserpublic requestApplicationvalidateand limitPrivate adapterallowed readsBitcoin Coreprivilegedinterface
Public explorer requests should cross a narrow boundary

Authentication is only one layer

Cookie authentication allows local software to obtain credentials from a protected file. Configured RPC users can provide another authentication mechanism. Protect credential files, process environments and any logs that might capture requests.

Authentication answers who can make a request. It does not by itself encrypt an untrusted network path, limit expensive calls, or ensure that an authenticated application is using only appropriate methods. A stolen administrator credential can still be dangerous even when a login prompt works perfectly.

Keep the network boundary narrow

Avoid exposing RPC directly to the public internet. Restrict listeners and network access to the intended local or controlled environment. If remote administration is necessary, use a deliberately secured access path rather than publishing a raw RPC endpoint and hoping its password will be enough.

Distinguish the public peer-to-peer service from the administrative interface. Allowing peers to exchange Bitcoin protocol messages does not require giving them RPC credentials.

EXAMPLE

A receipt generator does not need wallet control

A website prepares PDFs from public transaction facts. Its public API accepts a transaction ID, validates the format and calls a small internal reader. It has no reason to accept an arbitrary method name from a visitor or forward a visitor-supplied URL to the server. That boundary is narrower than giving the browser a general RPC proxy.

REST has a different authentication boundary

Bitcoin Core's optional REST interface exposes particular read-oriented resources and does not use RPC authentication in the same way. It can still reveal operational data and consume resources. Enabling REST must not be confused with granting a secure public application API.

The node's documentation describes resource concerns for large numbers of simultaneous requests. A separate application adapter should enforce endpoint allowlists, timeouts, response limits, concurrency limits and sensible caching.

Build for the version you run

RPC names, arguments and behavior can change across major releases. Wallet-specific requests can require a wallet endpoint rather than the root endpoint. Check local help and test integration assumptions against the intended version.

If a web application only needs public reads, separate it from signing keys and administrator credentials as far as practical. Store secrets outside source control and browser bundles. An error message should help the user retry without disclosing credential paths, request headers or private wallet data.

The operational goal is a small, auditable bridge from the website's needs to the node's capabilities. Running a node and exposing its full administration interface are separate decisions.

Sources and further reading

Share this guide
Share on X ↗

Key takeaways

  • RPC access can control important node and wallet behavior; it is not merely a public data API.
  • Authentication does not replace network isolation, encryption or method/resource limits.
  • Public explorer endpoints should validate requests and expose only the reads their features need.

Common questions

Can I put RPC credentials into frontend JavaScript?

No. Anything delivered to a browser must be treated as visible to its user; keep credentials in protected backend configuration.

Is REST automatically safe because it is read-oriented?

No. Data exposure and resource exhaustion still matter, and the interface needs an appropriate private network boundary.