How to secure an EVM RPC API key in production

Start by separating three authorities. An RPC credential admits requests to a service under its account rules. A management credential may change keys or account settings. A wallet signing key authorizes onchain transactions. Keep these in different access paths.

An RPC key does not sign a transaction. The Ethereum JSON-RPC method eth_sendRawTransaction submits bytes that have already been signed. Still, a leaked RPC key can cause quota use, throttling, or access to any RPC method that its policy allows. Map the application to the chains and methods it needs before creating credentials. A balance reader does not need transaction submission or tracing merely because those methods exist on the service.

For a server worker, store the key in a dedicated secret store or protected deployment secret and grant read access only to the workload that uses it. Keep it out of source files, build arguments, logs, support tickets, and analytics events. OWASP's secrets guidance recommends controlled storage, least privilege, auditing, rotation, and revocation.

A browser or distributed mobile app cannot keep a long-lived embedded key confidential from its users. If a request needs a private allowance or broad method access, send it through an authenticated application backend that holds the RPC credential and enforces the user's permitted operations. If direct client access is necessary, treat the credential as public, minimize its authority, and use only controls that the RPC service actually supports.

Do not mistake CORS for key protection. CORS controls which origins a browser may read from. It does not stop a copied credential from being used by a non-browser client. A source-IP restriction can be useful for stable server egress, but it is a poor fit for ordinary browsers or mobile devices with changing addresses.

Create separate credentials for production, test environments, local development, and distinct applications. Where the service supports it, restrict each key by chain, method, source, and request rate. Give a read-only process only the read methods it needs. Reserve heavier historical or trace access for the workers that require it. Apply a rate ceiling that fits measured normal and recovery traffic, then test that an expected burst still completes.

Document the intended caller, environment, chains, methods, and owner beside each key. Do not infer a restriction from a dashboard label or a successful call. Test that an allowed request succeeds and a deliberately disallowed chain, method, or source is rejected. The current SolidRPC API key security documentation describes its available controls and failure behavior. Check the live documentation before relying on a particular restriction.

Design rotation before the first incident. Issue a replacement with the same required scope, deploy it to one worker or environment, and confirm representative calls using that new key. Roll it through the remaining callers, then revoke the old key and verify it no longer works. Do not use a successful eth_blockNumber call as proof that the replacement can also serve required old state, logs, or traces.

Keep the overlap short and explicit. Track which deployments still use the old credential without copying the secret into a spreadsheet or ticket. If the service cannot keep two keys active during rotation, plan a bounded maintenance step and test it in a test environment first. OWASP recommends making secret rotation and revocation repeatable so that exposure does not require inventing a recovery procedure under pressure.

Record the key identifier or an internal alias, environment, chain, RPC method, timestamp, response class, and request volume. Track unexpected methods or networks, new source locations where available, unusual bursts, failed authentication, and quota pressure. Keep the actual key, full credential-bearing URL, authorization header, wallet secrets, and unnecessary request data out of logs and traces. OWASP's logging guidance treats primary secrets as data to exclude from event records.

Alert on behavior that indicates a real change, then compare it with deployments and planned backfills. A rate spike can be legitimate recovery traffic. An unknown caller or method needs investigation. Measure the application's useful completions as well as rejected calls so a security rule does not silently break the product.

Treat exposure as possible compromise even if you have not observed misuse. Create a replacement, switch intended callers, revoke the exposed key, and verify both that the new path works and that the old key is refused. Check usage and access records for the exposure period. Remove the secret from the visible artifact and investigate how it entered that path. Deleting a line from the current source file does not revoke a credential already copied from commit history or logs.

If the key was embedded in a released client, assume copies remain after a new app version ships. The fix is revocation and a safer access design, not only a client update. If the credential could reach account management or a transaction signer, examine those authorities separately. Do not assume an RPC-only credential gave an attacker a wallet private key, and do not assume a wallet is safe merely because RPC usage looks normal.

• Inventory every RPC caller and distinguish RPC, account management, and wallet signing authority.
• Keep private RPC credentials in server-side secret storage and remove them from client bundles and logs.
• Separate environments and applications by credential.
• Apply supported chain, method, source, and rate restrictions, then test both allowed and denied requests.
• Confirm the exact production methods and historical depth with the replacement key before rotation.
• Record a key alias and usage signals without recording the credential itself.
• Rehearse replacement, revocation, and verification in a controlled environment.
• Define who investigates unusual usage and how an exposed key is disabled.

A production key is ready when the team can explain its authority, identify its callers, replace it promptly, and prove that revocation works. The same review should be repeated when an application adds a network, a new RPC method, a browser client, or another worker.