Node.js 22 HTTPS by Default — A Field Guide

I want to flag the framing up front: Node.js has not made HTTP servers speak TLS by default, and the built-in http module still listens in plaintext unless you reach for https or http2 yourself. What Node 22 actually did is tighten the security posture around the network stack in smaller, less headline-grabby ways — stricter TLS defaults, continued work on the permission model, and deprecations that quietly close off insecure configurations. This is the more accurate — and more useful — story.

TLS minimum version enforcement

Node has been raising its effective minimum TLS version for years, and by the time you're on a current Node 22 build, TLS 1.0 and 1.1 are disabled at the OpenSSL layer by default — you have to explicitly opt back in with --tls-min-v1.0 if some ancient client or internal service genuinely needs it, which is rare in 2026. TLS 1.2 is the practical floor, and 1.3 is what any new client-server pair should negotiate. This isn't a Node 22-specific feature so much as it's a moving floor that Node 22 inherits and enforces more strictly than the LTS lines from a few years ago.

const https = require('node:https');
const fs = require('node:fs');

const server = https.createServer({
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  minVersion: 'TLSv1.2',   // explicit floor, don't rely on the runtime default alone
  ciphers: 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384',
});

server.listen(443);

The permission model is still experimental, but maturing

Node's --permission flag (with --allow-fs-read, --allow-fs-write, and friends) is not new to Node 22, but it kept maturing through the 22.x line — more of the standard library respects the granted permissions correctly, and fewer built-ins silently bypass the sandbox. It's the closest thing Node has to a network/filesystem security boundary comparable to Deno's, though it remains explicitly experimental and, unlike Deno, is opt-in rather than the default posture of every process.

Deprecations that close off insecure configurations

Each Node release deprecates a handful of APIs, and in the 22.x line several of them are security-adjacent: older, weaker crypto algorithms get runtime deprecation warnings before eventual removal, and some legacy URL-parsing behaviors that were a historic source of SSRF-style bugs are being tightened. None of this is a single dramatic change — it's the usual pattern of Node closing a few more of the footguns that built up over a decade of backward compatibility.

What this actually means for your production checklist

If your services already terminate TLS at a load balancer or reverse proxy — the common pattern for anything running behind nginx, Caddy, or a cloud provider's HTTPS load balancer — none of this changes your architecture. What it does mean: any Node process that terminates TLS directly should have its explicit minVersion set rather than trusting the runtime default silently, since that default has moved before and will move again. And if you maintain a service that still needs to talk to old TLS 1.0 peers, that's now something you have to opt into loudly instead of getting for free.

Wrapping up

There's no single "HTTPS by default" switch in Node 22 — the honest version of the story is a runtime that keeps raising its TLS floor, keeps working on a real permission sandbox, and keeps deprecating the insecure defaults it shipped a decade ago. Worth tracking, not worth assuming it replaces the reverse proxy or the load balancer doing your actual TLS termination.