Source code Security & compliance

TLS verification disabled

Part of the AI-generated code risks check · fix arrives as a pull request

What it is

TLS certificate verification is switched off — rejectUnauthorized: false, NODE_TLS_REJECT_UNAUTHORIZED=0, verify=False, or an equivalent — on a path that runs outside local development.

Why it matters

Verification is what makes TLS mean anything. Without it the connection is still encrypted but to whoever answered, so any network position between you and the service can read and rewrite the traffic.

The exact warning

If you run Cloudflare Tunnel, this is the line that appears in the cloudflared log once no-tls-verify is set for an origin — pipes included, which is why people paste it into Google verbatim:

WRN warning: | TLS certificate verification has been disabled! | originService=https://localhost:8443

The tunnel still encrypts traffic to your origin — it just no longer checks who it is encrypting to.

Every way it gets switched off

The same decision wears different syntax depending on the stack. All of these appear in AI-generated code as a “fix” for a certificate error somebody hit once:

// Node — per request
https.request({ rejectUnauthorized: false })

# Node — process-wide kill switch
NODE_TLS_REJECT_UNAUTHORIZED=0 node server.js

# Python requests
requests.get(url, verify=False)

# curl
curl -k https://internal.example.com

# cloudflared config.yml
originRequest:
  noTLSVerify: true

# git
git config http.sslVerify false

Why “encrypted anyway” is not a defence

Verification is the part of TLS that binds the encryption to an identity. Skip it and the handshake succeeds with whoever answered — your service, or anything on the path impersonating it. On a cloud network path that includes every proxy, load balancer and compromised hop in between: each can terminate the connection, read the traffic, rewrite it, and re-encrypt toward the real destination. Credentials and session tokens travel on exactly these connections.

Fix it properly — trust the CA instead

The error that prompted the shortcut is almost always a self-signed or internal-CA certificate. The fix is to teach the client the CA, not to stop checking:

// Node — pass the internal CA, keep verification on
import { readFileSync } from 'node:fs';
https.request({ ca: readFileSync('/etc/ssl/internal-ca.pem') });

# Python — point requests at the CA bundle
requests.get(url, verify='/etc/ssl/internal-ca.pem')
# or once, via environment
export REQUESTS_CA_BUNDLE=/etc/ssl/internal-ca.pem

# cloudflared — name the origin cert instead of disabling checks
originRequest:
  originServerName: internal.example.com

If a local-development exception truly is needed, scope it to an environment check that cannot evaluate true in production — never a default, never an environment variable that ships in a Dockerfile.

How lumioguard fixes it

The scan traces every outbound TLS client in the repo and flags disabled verification on paths that run outside local development. The fix arrives as a pull request on a lumioguard branch: verification re-enabled, the CA wired in where one is configured, and a breakage analysis attached listing each endpoint the change touches — you review and merge it.

Run them all on your app

Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.

Start for Free View pricing