Securing Public Endpoints with Proxy Access Rules

When your app is behind a reverse proxy, you have a free security checkpoint: every request passes through one process that can say no before the application even sees it. Enforcing access rules at that edge is faster, easier to audit, and safer than reimplementing the same checks as middleware in every service. This post covers the three rules that give the most protection for the least config: IP allowlists, rate limits, and method filtering.

Why enforce at the proxy

• **Early rejection.** A blocked request never consumes an app thread, a database connection, or a byte of compute.
• **One place to rule them.** Change the policy once and every app behind the proxy inherits it.
• **An auditable edge.** The proxy log shows the full chain: source IP, path, and the decision.

Be honest about the limitations too. The proxy knows IPs, paths, and headers — nothing about sub-resource or object-level authorization. It stops the noisy and obvious attacks; application authorization stays in the application.

IP allowlist for an admin panel

The classic pattern is to hide administration behind a CIDR that only staff can reach. Nginx checks the real client IP, which is why the trusted proxy config matters — see the header hygiene post for that dependency.

server {
    listen 80;
    server_name admin.example.com;

    allow 203.0.113.0/24;
    allow 127.0.0.1;
    deny all;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

The allow and deny directives run in order until one matches. Every request outside the two allowed ranges receives a 403 directly from the proxy, before touching your admin app. The single IP on the second line keeps localhost curl checks working while the management IP stays locked down.

Rate limiting the login endpoint

Password guessing is the one attack that looks like normal traffic, which is exactly why a per-IP counter belongs in front of it.

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    listen 80;
    server_name app.example.com;

    location /api/login {
        limit_req zone=login burst=5 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }
}

The zone stores counters in ten megabytes of shared memory keyed by the client IP at five requests per minute. The burst window absorbs five rapid attempts and nodelay means extra requests are rejected immediately rather than queued. Legitimately locked-out users plus one constant is fine; an attacker hammering login gets 503s instead of a dictionary audit trail.

Method and header filters

Restricting to the HTTP verbs your endpoints actually use removes a whole family of low-effort probes.

server {
    listen 80;
    server_name api.example.com;

    if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$) {
        return 405;
    }

    location /admin {
        deny all;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

The if block is one of the few uses of if that is safe inside a server context — it returns a 405 for anything outside the allowed verbs and stops. The location /admin deny kills a sensitive tree in one line regardless of what your framework would do with it. Order these before the general location so the deny wins.

Verify the rules bite

curl -s -o /dev/null -w "%{http_code}
" http://localhost/                   # 200
curl -s -o /dev/null -w "%{http_code}
" http://localhost/admin              # 403
curl -s -o /dev/null -w "%{http_code}
" -X OPTIONS http://localhost/        # 405
for i in $(seq 1 12); do curl -s -o /dev/null http://localhost/api/login; done

The last loop fires twelve login attempts and should end with 503 responses once the rate limit engages. When a rule does not bite, the usual causes are a spoofable client IP (fix the trusted proxy headers first) or the request matching a different server block than you think.

Takeaway

Three proxy rules — allowlists, per-IP rate limits, and method filters — neutralize most of what wants to reach your application. Enforce them at the edge, verify the real client IP is trustworthy, and your app only ever handles traffic that passed a decision. A DDoS-protected Netbay VPS in Lucknow DC01, with rules like these in front, gives you a proportionate first line of defense at netbayhosts.in.