Your RPC endpoint is part of your attack surface

Smart contracts get most of the attention in Web3 security reviews, and for good reason: they hold the funds. But almost every user interaction with a contract passes through a JSON-RPC endpoint first. The frontend asks a node for balances and allowances, simulates a transaction against it, estimates gas with it, and finally hands it the signed transaction to broadcast. Backends index events through the same interface.

Each of those steps trusts the node to tell the truth and to be available. This primer looks at what happens when it does not, and at the controls that keep a misbehaving or exposed RPC layer from turning into a loss.

What applications trust the node for

A typical application does not verify chain state itself. It does not check block headers against consensus or validate Merkle proofs for the storage it reads. It accepts whatever the provider returns. That is a reasonable engineering trade-off, but it should be a conscious one, documented in the threat model alongside the smart contracts.

When the answer is wrong

An RPC response can be wrong for innocent reasons, such as a node that is out of sync or a load balancer that routes consecutive requests to nodes at different heights, or for hostile ones: a compromised provider, a malicious public endpoint added by a user, or a network attacker who can substitute the endpoint a client connects to.

The impact depends on what the application does with the answer. Displaying a stale balance is an annoyance. Showing a simulation that hides a token drain, or crediting an off-chain account for an on-chain deposit that does not exist, is a loss. The guiding question for review is simple: for each RPC call, what decision does the result drive, and what is the worst outcome if the result is false?

Where the decision is consequential, applications can corroborate. Reading the same value from two independent providers at the same block makes a single lying provider detectable. Pinning reads to a specific block hash, rather than latest, ensures both providers answer about the same state.

1// Illustrative: read critical state from two independent providers2// at the same finalized block, and refuse to act if they disagree.3async function rpc(url: string, method: string, params: unknown[]) {4  const res = await fetch(url, {5    method: "POST",6    headers: { "content-type": "application/json" },7    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),8  })9  const { result, error } = await res.json()10  if (error) throw new Error(`${method}: ${error.message}`)11  return result12}13 14export async function verifiedBalance(address: string): Promise<bigint> {15  const block = await rpc(PRIMARY_RPC, "eth_getBlockByNumber", ["finalized", false])16  const at = { blockHash: block.hash }                     // EIP-1898 block reference17  const [a, b] = await Promise.all([18    rpc(PRIMARY_RPC, "eth_getBalance", [address, at]),19    rpc(SECONDARY_RPC, "eth_getBalance", [address, at]),20  ])21  if (a !== b) throw new Error("Providers disagree at the same block")22  return BigInt(a)23}

Simulation deserves particular care. Wallets and dApps increasingly show users the predicted effect of a transaction before they sign: tokens out, tokens in, approvals granted. That preview is only as honest as the node that produced it. A malicious endpoint can return a benign simulation for a harmful transaction, and some contracts behave differently when they detect that they are being simulated rather than executed, for example by checking block properties that differ between the two. Previews should come from infrastructure the application controls or trusts, and should be presented as a prediction rather than a guarantee.

Network identity

Every Ethereum-style transaction signature includes a chain ID, introduced by EIP-155 so that a transaction signed for one network cannot be replayed on another. That protection only helps if the chain ID is the one the user intended. Applications should read the chain ID from the connected provider, compare it with the network they expect, and refuse to construct or request signatures when the two differ.

The same applies to off-chain signatures. Typed-data domains carry a chain ID and a verifying contract; an application that builds the domain from the provider’s answer, rather than from its own configuration, lets a misconfigured or malicious endpoint steer users into signing for the wrong network or contract. Configuration that defines which chains and contracts an application works with should ship with the application and be treated as security-sensitive code.

Reorgs and finality

The latest block is not settled. Blocks near the head of the chain can be replaced, and with them the events a backend has already processed. Since the move to proof of stake, Ethereum’s JSON-RPC accepts safe and finalized as block parameters, which let applications read state that is far less likely, or under normal operation not expected, to be reverted.

Exposed nodes and leaked keys

Teams that run their own nodes inherit a second problem: the node’s administrative surface. Execution clients offer namespaces beyond the standard eth methods, for administration, debugging and transaction pool inspection. These are useful internally and dangerous when reachable from the internet. Older client versions also exposed account-management methods that could unlock keys held by the node; modern clients have deprecated or removed them, but legacy deployments persist.

1# Illustrative go-ethereum flags for an application-facing node.2# Bind to a private interface and expose only the namespaces the app needs.3geth \4  --http --http.addr 10.0.0.12 --http.port 8545 \5  --http.api eth,net,web3 \6  --http.vhosts rpc.internal.example \7  --http.corsdomain "https://app.example"8 9# Never expose admin, debug, txpool or legacy account namespaces10# to an untrusted network. Put authentication and rate limits in front.

Hosted providers shift that burden but introduce another: API keys embedded in frontend bundles. Anyone can read them. At best a leaked key lets others consume your quota and raise your bill; at worst, if the same key grants access to privileged methods or account features, it becomes a credential. Keys used in browsers should be restricted by origin and method at the provider, and separate from keys used by backends.

The write path

Broadcasting a transaction through a public endpoint exposes it to everyone watching the public mempool before it is included in a block. For trades and liquidations that is an invitation to front-running and sandwich attacks. Private submission services that forward transactions directly to block builders reduce that exposure, at the cost of trusting the service. Either way, contracts should not depend on transaction privacy for safety: slippage limits and deadlines belong in the transaction itself.

Availability is part of security as well. A protocol whose keepers, liquidators or guardians submit through a single provider can be stalled by that provider’s outage at exactly the wrong moment. Critical automation needs redundant endpoints and alerting when submissions fail.

Hardening the RPC layer

• List every RPC call the application makes and the decision each one drives; treat the list as part of the threat model.
• Corroborate consequential reads across independent providers, pinned to the same block.
• Credit deposits and trigger irreversible actions only from finalized data.
• Ship a pinned, integrity-checked list of endpoints and chain IDs; never fetch them over plain HTTP.
• Expose only the namespaces an application needs, on private interfaces, behind authentication and rate limits.
• Restrict browser-embedded API keys by origin and method; keep backend keys separate.
• Use redundant endpoints for keepers and guardians, with alerts on submission failures.

The choice between running nodes and buying access is not a choice between risk and safety. Self-hosting removes a third party from the trust path but adds patching, configuration and monitoring work that teams frequently underestimate. Hosted access is simpler to operate but concentrates trust and availability in a provider whose incidents become yours. Many teams settle on a hybrid: hosted providers for user-facing reads, a self-operated node for the reads that drive irreversible actions, and cross-checks between them. Whatever the arrangement, it should be written down, reviewed and tested like any other security control.

None of this replaces a sound contract. It makes sure that the decisions users and services take on the way to that contract are based on the same truth the contract will see.

Conclusions

An application is only as correct as the data it acts on, and in most stacks that data arrives unverified from an RPC provider. Wrong answers, lagging heads, reorganised blocks, exposed administrative interfaces and a single submission path are all ways an otherwise sound application can fail.

The controls are well understood and mostly operational: corroborate consequential reads, act on finalized data, pin network identity, minimise the exposed surface and make submission redundant.

Recommendations