Cloudflare tunnel endpoints authenticated
What this checks
Reads Cloudflare Tunnel configuration files to check whether services exposed via Cloudflare Tunnel have Access policies configured. Config is discovered from ~/.cloudflared/config.yml or /etc/cloudflared/config.yml the first file found is used. A tunnel without an Access policy is publicly reachable by anyone on the internet with no authentication. Additionally, the control detects other tunnel processes (ngrok, bore, frpc, Tailscale funnel) and flags them as requiring manual verification, since their auth configuration cannot be automatically assessed.
Why it matters
Cloudflare Tunnel is widely used by OpenClaw self-hosters to expose Slack webhooks and agent endpoints over the internet without opening firewall ports. The tunnel itself handles TLS, but it provides no authentication anyone who knows the URL (or finds it via DNS enumeration) can reach the origin service directly. Many developers assume the tunnel provides security; it does not. Cloudflare Access is a separate product that must be explicitly configured.
How to fix it
Option A Add a Cloudflare Access application (recommended)
In the Cloudflare dashboard: Zero Trust → Access → Applications → Add an application. Set it to protect your tunnel hostname. This puts a login page in front of your service no code changes needed.
Option B Use service tokens for machine-to-machine access
For webhook endpoints that don't need a human login page, use Cloudflare Service Tokens: create a token in Zero Trust → Access → Service Auth, then require it via an Access policy on the tunnel hostname.
Option C Add application-level auth to your service
Ensure the service behind the tunnel validates a secret on every request (e.g. OpenClaw webhook signing secret, or an API key header). This is defence-in-depth even if Cloudflare Access is bypassed or misconfigured, the origin rejects unauthenticated requests.
Verify your tunnel config is not set to bypass auth:
# Check whichever path exists on your system:
cat ~/.cloudflared/config.yml
cat /etc/cloudflared/config.yml
# Look for: access_required: true on each ingress hostname blockTechnical details
| Field | Value |
|---|---|
| Control ID | NC-TUNNEL-001 |
| Domain | NETWORK |
| Severity | High |
| Status | Expanded (Plugin only) |
| Data source | Filesystem scan ~/.cloudflared/config.yml or /etc/cloudflared/config.yml (read-only) + ps aux for other tunnel processes |
| Mode | Mode 2 (System-level requires plugin expanded mode) |
| Introduced in | Library v0.2.0 |
| Skipped if | No Cloudflare tunnel config found and no other tunnel processes detected |
| Other tunnels detected | ngrok, bore, frpc, Tailscale funnel flagged as informational (auth cannot be auto-assessed) |
False positive notes
Skipped automatically if no Cloudflare Tunnel config is found and no other tunnel processes are detected. If your tunnel endpoints are protected at the application layer (e.g. OpenClaw webhook signing) and Cloudflare Access is intentionally not used, exclude with a documented reason.
If ngrok, bore, frpc, or Tailscale funnel processes are detected, the control reports them as informational only it cannot automatically verify their authentication configuration. Review those services manually and exclude if they are intentionally in use.
Suppress this finding
clawvitals exclude NC-TUNNEL-001 reason "webhook endpoints protected by OpenClaw signing secret"