No Referrer-Policy header configured
The application sets neither helmet.referrerPolicy() nor a manual Referrer-Policy header, so full URLs (including any tokens or sensitive paths embedded in query strings) are leaked in the Referer header when users navigate to third-party origins or load cross-origin resources.
The security middleware block uses only helmet.noSniff() and helmet.frameguard(); helmet.referrerPolicy(...) is absent, and grep-equivalent inspection of the file shows no res.setHeader('Referrer-Policy', ...). Many of this app's URLs include identifiers and tokens (e.g. password reset, continue-code apply, basket IDs) that would be leaked via the default browser Referer behaviour to any cross-origin image, script, or link the user follows.
app.use(helmet.noSniff())
app.use(helmet.frameguard())
// no helmet.referrerPolicy(...) or res.setHeader('Referrer-Policy', ...)- Start the server and request any page.
curl -I http://localhost:3000/— noReferrer-Policyheader is returned.- A user clicking an outbound link, or loading any third-party
<img>/<script>, will send the full source URL (path + query) in theRefererheader to that third party.
All browser users. Sensitive query-string data (reset tokens, continue codes, IDs) can be exfiltrated to third-party origins via the default Referer behaviour, enabling account takeover or session correlation by external parties.
The security middleware block at lines ~186-194 only registers helmet.noSniff(), helmet.frameguard(), and featurePolicy(...), with no call to helmet.referrerPolicy(...) nor any res.setHeader('Referrer-Policy', ...) anywhere in the file. Without an explicit policy, browsers default to strict-origin-when-cross-origin in modern versions but no-referrer-when-downgrade historically — and the app routinely embeds sensitive tokens/IDs in URLs (e.g. /rest/continue-code/apply/:continueCode, /rest/user/reset-password, basket IDs), which can leak via the Referer header. The scope explicitly instructs treating findings as if this were a real production application, so the missing hardening header is a valid finding. Confirmed as a missing-security-headers bug, though impact is modest (best-practice hardening) rather than high-severity.
The middleware block at lines 186–194 registers only helmet.noSniff() and helmet.frameguard() with no helmet.referrerPolicy(...) or manual res.setHeader('Referrer-Policy', ...), so browsers fall back to default Referer behaviour and full URLs (including sensitive query params like the /rest/continue-code/apply/:continueCode token or password-reset paths registered later in the same file) are sent to third-party origins. Exploitation is network-reachable (AV:N) and requires no privileges (PR:N), but a victim must follow a cross-origin link or load a cross-origin sub-resource from a page whose URL happens to carry sensitive data, and the attacker must control or observe that third-party origin — hence UI:R and AC:H. Scope is Changed because the leaked data crosses into a different security authority (a third-party origin/log), and the impact is a partial confidentiality leak of whatever happens to be in the URL (C:L) with no integrity or availability effect.