Hardcoded cookie-parser signing secret 'kekse'

At line 267 the application wires up cookie-parser with a literal string secret:

app.use(cookieParser('kekse'))

The single string argument to cookieParser(...) is the secret used to sign cookies (e.g. via res.cookie(name, value, { signed: true })) and to verify signatures on incoming req.signedCookies. Because the value is checked into the repository, any attacker with read access to this open-source codebase knows the HMAC key used to sign cookies for every deployment that runs the unmodified server. The secret should be loaded from process.env, the config module (already imported above), or a secret manager, the same way other configuration values in this file are (config.get<string>('server.port'), config.get('application.securityTxt.contact'), etc.).

Note: this is the OWASP Juice Shop deliberately-vulnerable codebase, so the value is intentional for training purposes — but it nonetheless matches the criteria (real value, not a REPLACE_ME-style placeholder, used in a security-relevant signing context).

1. Read server.ts line 267 to learn the cookie signing secret: kekse.
2. Identify any signed cookie issued by the server (any call to res.cookie(name, value, { signed: true })).
3. Forge a cookie value and compute the signature with the known secret:

node -e "const c=require('cookie-signature');console.log(c.sign('attacker-controlled-value','kekse'))"

1. Replay the cookie back to the server; req.signedCookies will accept the forgery because the HMAC verifies under the leaked key.

Any deployment that ships this code uses a publicly-known HMAC key for signed cookies. An unauthenticated remote attacker can forge or tamper with any signed cookie the application trusts (session identifiers, CSRF tokens, preference flags, etc.) and bypass integrity checks. Rotation requires a code change and redeploy because the secret is not externalized.

Line 267 contains app.use(cookieParser('kekse')) with a literal string passed as the signing secret to cookie-parser, exactly as described. This secret is used to HMAC-sign cookies (via res.cookie(..., { signed: true })) and validate req.signedCookies; an attacker reading the public repo learns the key and can forge any signed cookie the server trusts. The scope explicitly says "Treat every finding as if this were a real production application" and not to dismiss findings due to Juice Shop's training nature. Other config values in the same file are correctly read via config.get(...), confirming externalization was feasible and was not done here.

The literal app.use(cookieParser('kekse')) at line 267 embeds the HMAC signing key in publicly readable source, so any unauthenticated remote attacker can compute valid signatures with cookie-signature.sign(value, 'kekse') and submit them over HTTP (AV:N, AC:L, PR:N, UI:N). The forged cookies are accepted by the same Express component via req.signedCookies, so impact stays within the vulnerable component (S:U). Because signed cookies in this app are used for non-primary auth state (the main session is a JWT in the Authorization header per verify.jwtChallenges() / security.isAuthorized()), the attacker gains the ability to tamper with arbitrary signed-cookie-trusted values (preferences, CSRF/state tokens, etc.) and can read/influence flows that depend on them, but does not get full disclosure or full control of backend data — hence C:L / I:L rather than H, and no DoS primitive (A:N).