Meteor 3.5

Apply the Node.js 24 prompt first. These rules cover Meteor's DDP methods and subscriptions, Mongo collections, Accounts and cookie sessions, Express handlers, and client and server bundles.

Runtime and application boundary

• Check the Node binary actually running the production bundle, independently of the Meteor tool and .meteor/release. If the bundled runtime lacks an upstream security fix, deploy with a compatible patched Node runtime and test native dependencies and the built application.
• Set ROOT_URL to the trusted HTTPS origin; keep MONGO_URL and private METEOR_SETTINGS out of client code and logs. Restrict BIND_IP, strip client-supplied forwarding headers, and set HTTP_FORWARDED_COUNT to the real proxy depth so secure-cookie and address-based decisions use trusted inputs.
• Keep secrets and privileged imports in server-only modules and private assets. A shared module's Meteor.isServer branch does not hide its source from the client; public/, Meteor.settings.public, Minimongo, source maps, and generated Rspack chunks are disclosure surfaces.
• Review .meteor/release, .meteor/versions, npm lockfiles, local packages, and rspack.config.js together. Treat build plugins and imported Rspack configuration as executable code and inspect the production client bundle for server-only data.

Methods and reactive authorization

• Validate all Meteor.methods and Meteor.publish arguments on the server with check or an exact schema. Bound lengths, arrays, nesting, and numbers; never treat Match.Any, Object, or Match.ObjectIncluding as