Meteor 3.3

Apply the Node.js 22 prompt first. These rules cover Meteor methods, DDP publications, collections, Accounts, HTTP handlers, and build output on the 3.3 line.

Runtime and deployment

• Inspect the Node binary that runs the built Meteor bundle as well as meteor node -v; the Meteor tool, production image, and deployed runtime can differ. When the bundled runtime lacks an upstream security correction, run the app with a compatible patched Node runtime and test native modules and the production bundle.
• The 3.3 startup MongoDB compatibility probe can accept an invalid TLS certificate and print a malformed MONGO_URL with credentials. Validate MONGO_URL before launch, restrict the probe to trusted MongoDB endpoints, protect startup logs, and rotate credentials if they appeared there. Correct settings on the main MongoDB driver do not repair this separate probe.
• Keep ROOT_URL on the intended HTTPS origin, MONGO_URL and METEOR_SETTINGS server-only, and BIND_IP behind the trusted proxy. Set HTTP_FORWARDED_COUNT to the actual proxy depth; strip client-supplied forwarding headers so address-based limits and secure-request decisions use trusted values.
• Review .meteor/release, .meteor/versions, npm lockfiles, build plugins, and local Atmosphere packages together. Keep secrets out of client modules, public/, Meteor.settings.public, source maps, and generated assets; a server-only branch in shared source does not make that source private.

Methods, DDP, and publications

• Check every untrusted Meteor.methods and Meteor.publish argument on the