Security Architecture — Series 2

Preview — 3 of 10 questions

This code listens for cross-window messages to receive an auth token from a trusted popup. What is the vulnerability, and what's missing?

javascript

window.addEventListener('message', (event) => {
  if (event.data.type === 'SET_TOKEN') {
    localStorage.setItem('token', event.data.token);
  }
});

AThis is safe as long as the page is served over HTTPS, since HTTPS automatically validates message origins.

BThe vulnerability is that postMessage is deprecated and no longer works in modern browsers.

CThe listener never checks event.origin, so any page — including a malicious one embedded in an iframe or opened as a popup — can send a { type: 'SET_TOKEN', token: '...' } message and have it accepted. An attacker could inject an arbitrary token to fixate the victim's session (or worse, if this pattern is reused for more sensitive data). The fix is to explicitly validate event.origin against an expected trusted origin before acting on the message.

DThere is no vulnerability — postMessage can only be sent by the page's own window, never by another origin.

What is the critical flaw in this token verification logic?

javascript

function verifyToken(token) {
  const decoded = jwt.decode(token, { complete: true });
  if (decoded.header.alg === 'none') {
    return decoded.payload; // trusts the payload without verifying a signature
  }
  return jwt.verify(token, SECRET_KEY);
}

Ajwt.decode throws an error whenever alg is "none", so this branch can never actually execute.

BThere is no flaw, since jwt.decode always cryptographically verifies the signature before returning a payload.

CThe flaw is that SECRET_KEY is too short, which is unrelated to the alg === 'none' branch.

DIt accepts tokens using the "none" algorithm — which, by design, carries no signature at all — and returns their payload as trusted without any cryptographic verification. An attacker can craft their own token with header {"alg":"none"} and any payload they like (e.g., {"isAdmin": true}), and this code accepts it as fully valid. Verification logic should never special-case or honor alg: none for anything security-sensitive.

This endpoint fetches a URL supplied by the client to generate a link preview. What is the vulnerability, and what could an attacker do with it?

javascript

app.post('/api/preview-link', async (req, res) => {
  const { url } = req.body;
  const response = await fetch(url); // fetches whatever URL the client provides
  const html = await response.text();
  res.send(extractTitle(html));
});

AThis is XSS, since extractTitle parses HTML content.

BThis is Server-Side Request Forgery (SSRF) — since the server itself makes the request to an attacker-chosen URL, an attacker can supply an internal address (e.g., a cloud metadata endpoint, or http://localhost:6379 for an internal service) that isn't reachable from the public internet but is reachable from the server's own network, potentially exposing internal services or cloud credentials that were never meant to be public.

CThis is CSRF, since the request is made with the POST method.

DThere is no vulnerability, since fetch can only access URLs that are already publicly accessible.

Answer all 10 questions (7 more), see explanations for every answer, and track your score.