Secure Ethereum JSON-RPC API with Nginx Password Protection

·

In the rapidly evolving world of blockchain development, securing your infrastructure is not optional—it's essential. For developers building decentralized applications (DApps) on Ethereum, exposing the JSON-RPC API to the public internet without protection can lead to serious security vulnerabilities, including denial-of-service attacks and unauthorized access to sensitive node operations.

This guide walks you through a robust, practical method to securely expose your Ethereum node’s JSON-RPC interface using Nginx as a reverse proxy with HTTP Basic Authentication. Whether you're showcasing a DApp demo, running a private blockchain network, or offering blockchain functionality as part of a SaaS solution, this setup ensures controlled and secure access.

Why Protect Your Ethereum JSON-RPC Endpoint?

The Go Ethereum client (geth) is one of the most widely used implementations for running Ethereum nodes. While powerful, geth does not include built-in mechanisms for securing its HTTP-based JSON-RPC API. By default, when you enable the HTTP API (--http flag), it listens on a port (commonly 8545) and can be accessed by anyone who can reach that endpoint.

Even if private APIs are disabled, leaving the JSON-RPC open invites abuse. Attackers can flood your node with requests, drain system resources, or probe for exploitable methods. Therefore, network-level protection is mandatory for any production or public-facing deployment.

👉 Discover how secure blockchain infrastructure supports reliable DApp performance

Using Nginx as a Secure Reverse Proxy

Nginx is a high-performance, open-source web server and reverse proxy that’s ideal for adding a security layer in front of your Ethereum node. By placing Nginx between the internet and your geth instance, you can:

This approach keeps geth simple and focused while offloading security concerns to a mature, battle-tested tool.

Core Keywords

Installing and Configuring Nginx

We’ll use Ubuntu 14.04+ as our base system, though the principles apply across Linux distributions.

Start by installing Nginx and apache2-utils, which includes the htpasswd tool for managing user credentials:

sudo apt install nginx apache2-utils

Next, configure Nginx to act as a reverse proxy. Edit the default site configuration:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    server_name demo.example.com;

    # Password-protected proxy for Ethereum JSON-RPC
    location /eth {
        auth_basic "Restricted access to this site";
        auth_basic_user_file /etc/nginx/protected.htpasswd;
        proxy_pass http://localhost:8545;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Serve static DApp files with authentication
    location / {
        root /usr/share/nginx/html;
        index index.html;
        auth_basic "Restricted access to this site";
        auth_basic_user_file /etc/nginx/protected.htpasswd;
    }
}

This configuration does two things:

  1. Routes /eth requests to the local geth node running on port 8545
  2. Serves your DApp’s frontend assets from /usr/share/nginx/html, both protected by login

Creating a Password-Protected User

Generate a username and encrypted password using htpasswd:

sudo htpasswd -c /etc/nginx/protected.htpasswd demo

You’ll be prompted to enter and confirm a password. The -c flag creates a new file; omit it for additional users.

👉 Learn how professional-grade tools enhance secure DApp deployment

Running Geth Securely in the Background

To keep your Ethereum node running persistently, use screen or systemd. Here’s a quick screen example:

screen
geth --http --http.addr 127.0.0.1 --http.port 8545 --http.api eth,net,web3 --syncmode "light"

Press Ctrl+A, then D to detach from the session while keeping geth running.

Note: Always bind geth to 127.0.0.1 (localhost) so it only accepts connections from the same machine—ensuring Nginx is the only gateway.

For production environments, consider using a systemd service file for automatic restarts and better process management.

Updating Your DApp to Use the Secure Endpoint

Modify your DApp’s front-end code (typically using web3.js) to connect via the Nginx proxy:

function getRPCURL() {
  if (window.location.href.includes("demo.example.com")) {
    return "http://demo.example.com/eth"; // Authenticated endpoint
  } else {
    return "http://localhost:8545"; // Local development
  }
}

web3.setProvider(new web3.providers.HttpProvider(getRPCURL()));

When users visit your site, their browser will prompt them for a username and password before allowing access—thanks to HTTP Basic Auth enforced by Nginx.

Deploying Your DApp Files

Copy your compiled DApp assets (HTML, JS, CSS) to Nginx’s document root:

sudo cp -r dist/* /usr/share/nginx/html/

Alternatively, use an automated script over SSH with rsync:

#!/bin/bash
set -e
set -u

REMOTE="your-server-name"
npm run build
rsync -a -e "ssh" --rsync-path="sudo rsync" dist/* --chown www-data:www-data $REMOTE:/usr/share/nginx/html/

Ensure proper file ownership so Nginx can serve the content without permission errors.

Restarting and Testing the Setup

After configuration changes, restart Nginx:

sudo service nginx stop
sudo service nginx start

Visit your domain in a browser. You should see a login prompt. After authenticating:

Check logs for troubleshooting:

tail -f /var/log/nginx/error.log

If you get a 502 Bad Gateway, verify that geth is running and accessible at localhost:8545.

Frequently Asked Questions (FAQ)

Q: Is HTTP Basic Authentication secure enough?
A: It’s suitable for low-to-medium risk scenarios like demos or internal tools. Always use HTTPS in production to encrypt credentials during transmission.

Q: Can I use API keys instead of passwords?
A: Yes—Nginx can be configured to validate custom headers or tokens. However, HTTP Basic Auth offers simplicity and broad compatibility.

Q: What happens if someone guesses the password?
A: Use strong passwords and consider rate-limiting with Nginx (limit_req_zone) to prevent brute-force attacks.

Q: Does this setup work with other Ethereum clients?
A: Absolutely. Whether you're using Parity, OpenEthereum, or Besu, any client exposing an HTTP JSON-RPC API can be protected behind Nginx.

Q: Should I expose my node directly if I have a firewall?
A: Firewalls help but aren’t foolproof. A reverse proxy adds authentication, logging, and defense-in-depth—critical layers beyond IP filtering.

Q: Can I host multiple DApps with different credentials?
A: Yes. Nginx supports multiple location blocks with separate auth_basic_user_file directives for granular access control.

👉 Explore secure blockchain development practices trusted by professionals

Conclusion

Securing your Ethereum JSON-RPC API doesn’t require complex tools or expensive services. With Nginx as a reverse proxy and HTTP Basic Authentication, you gain an effective barrier against unauthorized access—without modifying your DApp logic or node software.

This setup is lightweight, reliable, and easy to maintain, making it ideal for developers who need to safely expose blockchain functionality over the internet. As decentralized applications grow in complexity and adoption, foundational security practices like these become increasingly vital.

By integrating these steps into your deployment workflow, you ensure that your DApp remains both accessible and protected—delivering value without compromising integrity.