← Back to question bank
QuizSeniorHard#521 · 25mFinance specialization

Explain XSS/CSP risks from rich frontend experience

Connect rich-text/editor experience to sanitization, trusted HTML boundaries, CSP, and dependency hygiene.

Answer Strategy

For xSS/CSP risks from rich frontend experience, do not answer like a glossary entry. State the rule, show where it appears in product UI, then name the user-visible bug that happens when the rule is misunderstood.

A strong foundation answer has three layers: the browser or language model, a tiny code example, and a frontend consequence such as stale state, broken focus, blocked input, unsafe data, or flaky tests.

The reference example below is intentionally small but production-shaped: it names the boundary, protects the failure mode, and includes a test that proves the rule instead of relying on explanation alone.

Reference Example: Runtime Ordering

Use a small trace to show exactly how sync work, microtasks, timers, and render opportunities interact.

function traceRuntimeOrder() {
  const events: string[] = [];
  events.push('sync: render work starts');

  queueMicrotask(() => events.push('microtask: promise continuation'));
  Promise.resolve().then(() => events.push('microtask: resolved promise'));
  setTimeout(() => events.push('timer: later task'), 0);

  events.push('sync: render work ends');
  return events;
}

Testing Strategy

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

Rule
State the browser, JavaScript, TypeScript, CSS, security, or accessibility rule in one sentence.
Product bug
Connect the rule to a concrete UI failure: stale data, blocked input, broken focus, layout shift, or unsafe trust boundary.
Proof
Use a tiny test, trace, or code review checklist item that would catch the misunderstanding.
test('synchronous work finishes before queued microtasks', async () => {
  const events = traceRuntimeOrder();
  expect(events).toEqual(['sync: render work starts', 'sync: render work ends']);

  await Promise.resolve();
  expect(events).toContain('microtask: promise continuation');
  expect(events).not.toContain('timer: later task');
});

Interviewer Signal

This lets you reuse your editor background in a finance context.

Constraints

  • Keep local, backend, wallet, chain, and user-visible state distinct.
  • Name the product risk before naming the component.
  • Tie the answer back to testing or rollout safety.

Model Answer Shape

  • Connect rich-text/editor experience to sanitization, trusted HTML boundaries, CSP, and dependency hygiene.
  • Use explicit ownership boundaries for state, data, and user intent.
  • Describe how the UI prevents misleading certainty during pending or failed operations.

Tradeoffs

  • Finance-grade UI should be conservative about certainty and optimistic about continuity.
  • Local state improves recovery but must not pretend to be canonical business truth.

Edge Cases

  • Refresh during pending work.
  • Duplicate user intent.
  • Backend, wallet, and chain disagree temporarily.

Testing And Proof

  • State transition test.
  • Reload recovery scenario.
  • Accessible status and copy review.

Follow-Ups

  • What would you log for support?
  • How would you roll this out behind a flag?

Deep Finance Practice

This item has an authored finance specialization page with the original prompt, solution, and any available runnable harness.

Open legacy practice #521 ->