Which setting wins

A security setting comes from one of three places, and the later one wins for the key it sets:

1. the handler's defaults (what is on by default, below);
2. security in dusk.config.ts, which is written into the server bundle as plain data (no secrets, no functions);
3. src/entry-server.ts, where a secret, a function (requestId, a custom onError) or any option the file cannot carry goes.

The values the generated entry fixes come last and are not overridable: the manifest and the mount point. The merge is per key, at any depth (mergeHandlerOptions; the full rules are in Merging the entry's options). So the entry's security.csp keeps the file's security.headers and security.allowedHosts. Three cases to know:

• Coexisting. security.headers in the file and security.csp in the entry both apply: the response carries both headers.
• Turning off. security.csp: false (or headers: false, csp: false in the entry) disables a setting the file declares. false and null override; an explicit undefined does not.
• Replacing a list. security.allowedHosts in the entry replaces the file's list, it is not added to it. An entry that sets allowedHosts: [] removes the host check, and in production that needs acknowledgeNoHostCheck: true.

When the same leaf is set in both files with different values, the build warns once, naming the leaf, and the entry's value is in force (see Conflicts between the file and the entry).