security: gateway public network hardening by yeyanle6 · Pull Request #44884 · openclaw/openclaw

yeyanle6 · 2026-03-13T08:50:43Z

Summary

Implements comprehensive security hardening for OpenClaw Gateway when exposed to public networks (e.g. https://openclaw.allegro.earth/). The existing security mechanisms (non-loopback auth enforcement, auth rate limiting, CORS checks) leave gaps that this PR addresses:

IP access control (allowlist/blocklist with CIDR support) — enforced on both HTTP requests and WebSocket upgrades, loopback always allowed, blocklist takes priority
Password/token strength validation — CRITICAL startup warnings when network-exposed with short tokens (<32 chars) or weak passwords (<12 chars, all-digit/all-letter patterns)
TLS enforcement check — CRITICAL startup warning when network-exposed without TLS and no terminatedUpstream declaration
Per-IP request rate limiting — sliding window (default 120 req/min/IP), loopback exempt by default, returns 429 with Retry-After
Auth audit logging — JSONL to ~/.openclaw/logs/gateway-auth.jsonl with file rotation, records auth_failure, auth_success, rate_limited, ip_blocked events
Auto HSTS — Strict-Transport-Security: max-age=31536000 set automatically when TLS is enabled
Eliminate silent 0.0.0.0 fallback — loopback, tailnet, and custom bind modes now throw clear errors instead of silently falling back to all-interfaces
New security audit checks — gateway.no_tls_network_exposed (critical), gateway.password_too_short (critical), gateway.password_weak_pattern (warn), gateway.no_request_rate_limit (warn), gateway.auto_bind_fallback (warn)
Enhanced doctor warnings — TLS, password strength, token length, request rate limit checks for network-exposed gateways

Config additions (`gateway.*`)

Key	Type	Default	Description
`ipAllowlist`	`string[]`	—	CIDR/IP allowlist (loopback always allowed)
`ipBlocklist`	`string[]`	—	CIDR/IP blocklist (checked before allowlist)
`requestRateLimit.maxRequests`	`number`	120	Max requests per IP per window
`requestRateLimit.windowMs`	`number`	60000	Sliding window duration (ms)
`requestRateLimit.exemptLoopback`	`boolean`	true	Skip rate limiting for localhost
`tls.terminatedUpstream`	`boolean`	false	Declare TLS terminated by reverse proxy

Test plan

pnpm tsgo — type check passes
New unit tests: ip-access-control.test.ts (9 tests), request-rate-limit.test.ts (7 tests), auth-audit-log.test.ts (4 tests), credential-strength.test.ts (9 tests)
Existing tests updated and passing: server-runtime-config.test.ts, doctor-security.test.ts, net.test.ts, auth.test.ts, audit.test.ts — 245 tests total
Manual: start gateway with bind=lan and verify startup warnings
Manual: test IP blocklist returns 403
Manual: test request rate limit returns 429

🤖 Generated with Claude Code

- IP access control (allowlist/blocklist) for HTTP and WebSocket paths - Password/token strength validation with CRITICAL startup warnings - TLS enforcement check for network-exposed gateways - Per-IP request rate limiting (120 req/min default) - Auth audit logging (JSONL) for auth failures, IP blocks, rate limits - Auto HSTS header when TLS is enabled - Eliminate silent 0.0.0.0 fallback in loopback/tailnet/custom bind modes - New security audit checks: no_tls, password strength, request rate limit, auto bind - Enhanced doctor-security warnings for TLS, password, token, rate limit - Unit tests for all new modules (IP control, rate limit, audit log, credential strength) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

greptile-apps · 2026-03-13T08:54:10Z

Greptile Summary

This PR adds a comprehensive set of public-network security hardening features to the OpenClaw Gateway: IP allowlist/blocklist with CIDR support, per-IP request rate limiting, credential strength validation, TLS enforcement warnings, auth audit logging, auto-HSTS, and elimination of silent 0.0.0.0 bind fallbacks. The implementation is generally solid and well-tested, but there are a few gaps worth addressing:

WebSocket IP blocks not audit-logged — attachGatewayUpgradeHandler doesn't receive authAuditLogger, so blocked WebSocket upgrade attempts produce no ip_blocked audit entry, unlike HTTP requests.
authAuditLogger not flushed on shutdown — The shutdown sequence calls requestRateLimiter.dispose() but never authAuditLogger.flush(), risking loss of the last queued log entries on graceful stop.
auth_failure / auth_success events declared but never emitted — The type, the module docstring, and the PR description all state the logger records authentication outcomes, but no call sites for these events exist in this PR.
Misleading gateway.no_request_rate_limit warning — The rate limiter is always created with defaults (120 req/min/IP) regardless of explicit config. The doctor and audit findings that fire when no explicit requestRateLimit config is set claim rate limiting is absent, when it is actually active with defaults.

Confidence Score: 3/5

Safe to merge with minor issues; the security hardening is effective but the audit log has gaps (WebSocket blocks unlogged, auth events unimplemented, no shutdown flush) and one misleading operator-facing warning.
Core security controls (IP ACL, rate limiting, credential checks, TLS warnings) are correctly implemented and tested. The gaps are in observability completeness (audit log) and messaging accuracy (misleading warning), not in the enforcement path itself.
src/gateway/server-http.ts (WebSocket audit logging gap), src/gateway/server.impl.ts (missing flush on shutdown), src/gateway/auth-audit-log.ts (unused event types), src/security/audit.ts (misleading no-rate-limit finding)

Comments Outside Diff (1)

src/security/audit.ts, line 1317-1327 (link)

gateway.no_request_rate_limit finding is misleading — rate limiting is always active

createRequestRateLimiter(cfgAtStart.gateway?.requestRateLimit) is called unconditionally in server.impl.ts with defaults (120 req/min/IP, loopback exempt). Because requestRateLimiter is never null, the if (requestRateLimiter) guard in server-http.ts always fires, meaning rate limiting is always active even when no explicit config is present.

The finding here fires when !cfg.gateway?.requestRateLimit, with the detail "Without request rate limiting, the gateway is more vulnerable to abuse" — which is factually incorrect at runtime. The same problem exists in doctor-security.ts where the same condition triggers a "No per-IP request rate limiting configured" warning.

The message should clarify that defaults are applied automatically and the warning encourages explicit configuration, e.g.:

"gateway.requestRateLimit uses default limits (120 req/min/IP). Set it explicitly to acknowledge and tune this behavior."

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/security/audit.ts
Line: 1317-1327

Comment:
**`gateway.no_request_rate_limit` finding is misleading — rate limiting is always active**

`createRequestRateLimiter(cfgAtStart.gateway?.requestRateLimit)` is called unconditionally in `server.impl.ts` with defaults (`120 req/min/IP`, loopback exempt). Because `requestRateLimiter` is never `null`, the `if (requestRateLimiter)` guard in `server-http.ts` always fires, meaning **rate limiting is always active** even when no explicit config is present.

The finding here fires when `!cfg.gateway?.requestRateLimit`, with the detail _"Without request rate limiting, the gateway is more vulnerable to abuse"_ — which is factually incorrect at runtime. The same problem exists in `doctor-security.ts` where the same condition triggers a _"No per-IP request rate limiting configured"_ warning.

The message should clarify that defaults are applied automatically and the warning encourages explicit configuration, e.g.:
> "gateway.requestRateLimit uses default limits (120 req/min/IP). Set it explicitly to acknowledge and tune this behavior."

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/gateway/server-http.ts
Line: 1000-1003

Comment:
**WebSocket IP blocks not logged to audit log**

When a WebSocket upgrade is blocked by the IP access control check, no `ip_blocked` event is emitted to `authAuditLogger`. The `attachGatewayUpgradeHandler` function doesn't accept `authAuditLogger` as a parameter at all, so blocked WebSocket connections are silently dropped without any audit trail — unlike HTTP requests, which correctly log the event.

Consider adding `authAuditLogger` to the options of `attachGatewayUpgradeHandler` and emitting the event here:
```
if (!wsIpCheck.allowed) {
  authAuditLogger?.log({ event: "ip_blocked", clientIp: upgradeClientIp ?? undefined });
  socket.write("HTTP/1.1 403 Forbidden\r\n\r\n");
  socket.destroy();
  return;
}
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/gateway/server.impl.ts
Line: 1078-1080

Comment:
**`authAuditLogger` not flushed on shutdown**

The shutdown sequence disposes `requestRateLimiter` but never calls `authAuditLogger.flush()`. Since `log()` enqueues writes as a promise chain, any entries logged close to shutdown (e.g. a final rate-limited event or IP block) may not be fully written to disk before the process exits.

The `AuthAuditLogger` interface already exposes a `flush()` method for this purpose:
```
requestRateLimiter.dispose();
await authAuditLogger.flush();   // flush before close
channelHealthMonitor?.stop();
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/gateway/auth-audit-log.ts
Line: 13

Comment:
**`auth_failure` and `auth_success` events are never emitted**

The `AuthAuditEventType` union and the module-level docstring both promise that `auth_failure` and `auth_success` events are recorded, and the PR description calls this out explicitly. However, neither event is actually logged anywhere in the current diff — `authAuditLogger` is only called with `ip_blocked` and `rate_limited` in `server-http.ts`.

This leaves the audit log incomplete for its primary purpose (auditing authentication outcomes). Consider either wiring up these events in the auth code paths or removing them from the type until they are implemented, to avoid misleading operators who inspect the log file expecting auth event coverage.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/security/audit.ts
Line: 1317-1327

Comment:
**`gateway.no_request_rate_limit` finding is misleading — rate limiting is always active**

`createRequestRateLimiter(cfgAtStart.gateway?.requestRateLimit)` is called unconditionally in `server.impl.ts` with defaults (`120 req/min/IP`, loopback exempt). Because `requestRateLimiter` is never `null`, the `if (requestRateLimiter)` guard in `server-http.ts` always fires, meaning **rate limiting is always active** even when no explicit config is present.

The finding here fires when `!cfg.gateway?.requestRateLimit`, with the detail _"Without request rate limiting, the gateway is more vulnerable to abuse"_ — which is factually incorrect at runtime. The same problem exists in `doctor-security.ts` where the same condition triggers a _"No per-IP request rate limiting configured"_ warning.

The message should clarify that defaults are applied automatically and the warning encourages explicit configuration, e.g.:
> "gateway.requestRateLimit uses default limits (120 req/min/IP). Set it explicitly to acknowledge and tune this behavior."

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: e0f0938}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e0f0938771

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Niraven · 2026-03-13T09:12:50Z

🔒 Automated Security Assessment

Status: ⚠️ REVIEW REQUIRED — Potential security issues detected.

Scan Date: 2026-03-13 09:12 UTC
Scanner: axis-main PR Security Scanner

Checks Performed

Check	Result
Hardcoded secrets / credentials	🔴 CRITICAL
SQL injection risk (unprepared queries)	✅ Pass
Dangerous code execution (eval/exec/system)	✅ Pass
Sensitive file path exposure (.env, .key, .pem)	✅ Pass
New dependency additions	✅ Pass

Findings

🔴 CRITICAL: Potential hardcoded credential detected

The scanner found a pattern matching hardcoded secrets:

process.env.OPENCLAW_GATEWAY_TOKEN = "token-123";

Assessment: This appears to be a test fixture value in src/commands/doctor-security.test.ts. If so, this is likely not a real secret — placeholder/dummy values in test files are generally acceptable. However, please confirm:

This token is not a real/valid credential
Test files are not accidentally committing real tokens
Any real token values are pulled from environment variables, not hardcoded

Context

This is a security hardening PR (gateway public network hardening with 18 files changed). The finding is very likely a test stub. Manual review recommended to confirm test tokens are fake.

Recommendation

✅ If token-123 is a placeholder test value: No action needed — please confirm in a reply.
⛔ If any real credentials were accidentally included: Rotate immediately and use env vars or secrets management.

This comment was posted by the automated PR security scanner. False positives may occur — please verify findings manually.

- Log ip_blocked audit events for WebSocket upgrade blocks - Flush authAuditLogger on graceful shutdown - Wire auth_failure/auth_success audit events into auth paths - Fix misleading no_request_rate_limit warning (defaults are active) - Honor strictTransportSecurity=false opt-out when TLS auto-HSTS is enabled Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

yeyanle6 · 2026-03-13T09:29:00Z

Confirmed: token-123 is a placeholder test fixture value in src/commands/doctor-security.test.ts, not a real credential. No action needed.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7d4bb8c390

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

…t rate limiting

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f45ec1b14b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

openclaw-barnacle · 2026-04-28T04:43:16Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

clawsweeper · 2026-04-28T05:55:16Z

Codex review: needs maintainer review before merge.

Summary
Review failed before ClawSweeper could summarize the requested change.

Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path.

Next step before merge
Review did not complete, so no work-lane recommendation was made.

Review details

Best possible solution:

Retry the Codex review after fixing the execution failure.

Do we have a high-confidence way to reproduce the issue?

Unclear. The review failed before ClawSweeper could establish a reproduction path.

Is this the best way to solve the issue?

Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction.

What I checked:

failure reason: codex execution failed.
codex failure detail: Codex review failed for this PR with exit 1.
codex stdout: Per-item Codex failure; continuing with the rest of the shard.

Likely related people:

unknown: Codex failed before it could trace repository history. (role: review did not complete; confidence: low)

Remaining risk / open question:

No close action taken because the review did not complete.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9c37cfcbdbf7.

…audit Gap 1 (Critical CWE-208): Replace !== with safeEqualSecret() for TLS fingerprint comparison in client.ts, eliminating timing side-channel attacks on WebSocket and HTTP TLS pinning. Refs: openclaw/openclaw#49083 Gap 2 (High revocation race): Add sync invalidated flag on GatewayClient, set before respond() in device.token.rotate/revoke and device.pair.remove handlers, with per-RPC dispatch guard in message-handler to reject pipelined RPCs from revoked credentials. Refs: openclaw/openclaw#70707 Gap 4 (High unbounded sessions): Add authenticated-connection-budget.ts per-device connection cap (default 8) with env override. Refs: openclaw/openclaw#59842 Gap 6 (High HTTP flood): Add request-rate-limit.ts sliding-window per-IP HTTP request rate limiter (default 120/min) for REST endpoints. Refs: openclaw/openclaw#44884 Gap 7 (High TLS enforcement): Add startup-security-checks.ts for network-exposure safety checks at startup. Refs: openclaw/openclaw#44884 Gap 8 (Medium auto HSTS): Auto-inject HSTS when TLS is active. Refs: openclaw/openclaw#44884 Gap 9 (Medium bind safety): Bind-all-interfaces detection via startup checks. Refs: openclaw/openclaw#44884 Gaps 3, 5, 10 already fixed in fork — no changes needed.

openclaw-barnacle Bot added gateway Gateway runtime commands Command implementations size: XL labels Mar 13, 2026

greptile-apps Bot reviewed Mar 13, 2026

View reviewed changes

Comment thread src/gateway/server-http.ts

Comment thread src/gateway/server.impl.ts

Comment thread src/gateway/auth-audit-log.ts

chatgpt-codex-connector Bot reviewed Mar 13, 2026

View reviewed changes

Comment thread src/gateway/server-runtime-config.ts Outdated

Merge branch 'main' into 2026-03-13

7d4bb8c

chatgpt-codex-connector Bot reviewed Mar 13, 2026

View reviewed changes

Comment thread src/security/audit.ts Outdated

Comment thread src/gateway/server-http.ts

security: fix false positives for custom loopback bind & add WebSocke…

f45ec1b

…t rate limiting

yeyanle6 requested a review from a team as a code owner March 15, 2026 23:24

chatgpt-codex-connector Bot reviewed Mar 15, 2026

View reviewed changes

Comment thread src/security/audit.ts

Comment thread src/gateway/server-http.ts

security: treat bind=tailnet as non-public-exposed in audit checks

84960ed

BingqingLyu mentioned this pull request Apr 27, 2026

security: gateway public network hardening BingqingLyu/openclaw#601

Open

6 tasks

openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Apr 28, 2026

clawsweeper Bot mentioned this pull request Apr 28, 2026

feat(gateway): add general per-IP request rate limiter #48336

Open

4 tasks

openclaw-barnacle Bot removed the stale Marked as stale due to inactivity label Apr 29, 2026

Uh oh!

Conversation

yeyanle6 commented Mar 13, 2026

Summary

Config additions (gateway.*)

Test plan

Uh oh!

greptile-apps Bot commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 3/5

Comments Outside Diff (1)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Niraven commented Mar 13, 2026

🔒 Automated Security Assessment

Checks Performed

Findings

Context

Recommendation

Uh oh!

yeyanle6 commented Mar 13, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

openclaw-barnacle Bot commented Apr 28, 2026

Uh oh!

clawsweeper Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Config additions (`gateway.*`)

greptile-apps Bot commented Mar 13, 2026 •

edited

Loading

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading