In Yarn Berry, npmRegistryServer sets the default registry and npmScopes routes specific scopes to other registries, each with its own auth token. URLs must use HTTPS by default, enableStrictSsl is true by default, and npmAlwaysAuth stays false unless you point at a private mirror that needs credentials on every request.
The pieces
From the Yarn configuration reference:
| Setting | What it does | Default or example |
|---|---|---|
| npmRegistryServer | Registry used when fetching packages | https://registry.yarnpkg.com |
| npmScopes | Per-scope registry configuration | one block per scope name |
| npmAuthToken | Token for a registry | set per registry or scope |
| npmAlwaysAuth | Send credentials on every request to the registry | false |
| npmAuditRegistry | Registry used for audits | falls back to npmRegistryServer |
| enableStrictSsl | Fail requests on SSL errors | true |
| unsafeHttpWhitelist | Hostname globs where plain HTTP is allowed | empty |
The docs say the registry URL must use HTTPS by default, and the only way around it is the whitelist.
A private scope example
# .yarnrc.yml
npmScopes:
my-company:
npmRegistryServer: "https://npm.internal.example"
npmAuthToken: "${INTERNAL_NPM_TOKEN}"
Packages under the my-company scope go to the internal host with its token. Everything else goes to the default registry. That routing is what keeps internal package names from being requested from the public registry, which is the setup that dependency confusion attacks rely on being absent. See npm scopes and package name collisions.
Keep the token in an environment variable, not in the committed file.
Do not weaken TLS
Two settings are tempting when a corporate proxy causes errors: adding a host to unsafeHttpWhitelist, and setting enableStrictSsl to false. The docs state that with strict SSL off, certificate errors are ignored. Either change lets anyone on the network path read or change what you download. Integrity hashes in the lockfile still catch altered tarballs, but they do not protect credentials sent in the clear, and metadata can be altered to steer resolution.
Better fixes:
- Install your proxy's certificate authority properly on the build machines.
- Use HTTPS on the internal registry.
- If you must allow HTTP for a legacy host, whitelist exactly that host with a comment, and plan its removal.
npmAlwaysAuth
The docs say this should not be needed unless you configured the registry to reference a private npm mirror. If you set it to true, credentials are sent with every request to that registry, so be sure the host is the one you intend. Do not set it for the public registry.
Audit registry
npmAuditRegistry defaults to your npmRegistryServer. If your internal mirror does not implement the audit endpoint, audits may fail or silently lack data, so confirm that your audit source is what you think. Our post on what yarn npm audit and pnpm audit check covers that.
A short review checklist
- Every internal scope has an entry in npmScopes.
- No literal tokens in committed files.
- enableStrictSsl is not set to false anywhere.
- unsafeHttpWhitelist is empty or minimal.
- CI installs from a clean checkout with the same settings.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation read your lockfile and record where each component resolved, and policies and gates can flag unexpected sources in a pull request. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Does Yarn allow an HTTP registry by default?
No. The docs say the URL must use HTTPS by default, and the only exception is a host listed in unsafeHttpWhitelist.
Is it safe to set enableStrictSsl to false behind a proxy?
No. It makes Yarn ignore certificate errors. Install the proxy's certificate authority instead.
Sources
Last reviewed: 19 October 2026.
