All jobs / Frontend / web developer

Security interview questions

Security questions a Frontend / web developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. Marketing wants to render a CMS HTML snippet in React. Strongest answer?

    The strongest answer: Don't put untrusted HTML through dangerouslySetInnerHTML — sanitize with a maintained library or store structured fields

    Why it works: XSS is a browser issue you own. Prefer structured content; if HTML is required, sanitize on a known-good allowlist.

    • Treat HTML as untrusted.
    • Prefer structured fields over HTML.
    • If you must render HTML, sanitize on an allowlist.
    • Never mix raw user text into HTML strings.

  2. A cookie-session SPA posts state-changing requests. What do you do in the browser about CSRF?

    The strongest answer: Use SameSite=Lax or Strict cookies, send a CSRF token or a custom header on mutations, and don't assume Origin is always present

    Why it works: Cookie auth means CSRF is your problem: SameSite plus a token or custom header on POST/PUT/DELETE.

    • Cookie sessions need CSRF defenses.
    • SameSite on the cookie.
    • Token or custom header on mutations.
    • Don't 'fix' CSRF by moving secrets into JS storage without owning XSS.

  3. Auth token in localStorage versus an httpOnly cookie for a SPA — how do you argue it?

    The strongest answer: Prefer httpOnly + Secure + SameSite cookies so XSS cannot steal the session; add CSRF protections for cookie auth

    Why it works: The 2026 default in this room: cookies you cannot read from JS, plus CSRF on mutations. Name XSS as the reason.

    • Assume XSS will be tried.
    • Session in httpOnly Secure SameSite cookies.
    • CSRF token or custom header on writes.
    • Don't put bearer tokens in localStorage by default.

  4. You need a small inline boot script but CSP forbids unsafe-inline. What do you do?

    The strongest answer: Give that script a nonce or hash; keep unsafe-inline and eval off; load analytics only after consent

    Why it works: CSP is doing its job. Nonce- or hash-based allowlists are the supported door.

    • Keep a strict CSP.
    • Nonce or hash the boot script.
    • No eval, no unsafe-inline.
    • Third-party tags wait for consent.

  5. Two 401s trigger two refresh calls and one of them logs the user out. How do you design the client?

    The strongest answer: Single-flight the refresh, queue the original requests, retry them, and log out only when refresh fails

    Why it works: Refresh is a critical section. One in-flight refresh, everyone else waits.

    • One refresh at a time.
    • Queue callers.
    • Retry originals after success.
    • Logout only on refresh failure; keep refresh out of JS if you can.

  6. Product wants full click tapes plus form field values in the frontend logger. How do you respond?

    The strongest answer: Minimize: no secrets or PII in RUM, scrub fields, purpose-limit the log, and run it past privacy

    Why it works: Frontend logs are production data. Minimization and purpose are the staff answer, not a bigger tape.

    • Collect less than product asked.
    • Scrub inputs and secrets.
    • State the purpose.
    • Never log passwords, even temporarily.

  7. Legal says marketing pixels cannot run before consent. How do you architect the frontend?

    The strongest answer: A CMP gate: load tags only after purpose consent, honor region and withdrawal, and set no marketing cookies before that

    Why it works: Consent is a load-order problem. Pixels are code; they do not run until the purpose is granted.

    • Consent before tags.
    • CMP as the gate.
    • Purpose IDs, not one boolean.
    • Withdrawal unloads tags and clears that purpose.

  8. A junior's PR works but has an XSS hole and no tests. How do you mentor in review?

    The strongest answer: Block the vuln, explain the path, pair on a test, and don't shame them

    Why it works: Security is non-negotiable; the lesson is the point of seniority. Pairing beats a drive-by fix.

    • Protect users, then teach.
    • Do not merge the hole.
    • Walk the failure mode.
    • Write the test together.

  9. How do you keep consent state consistent across web, a WebView, and a pixel manager?

    The strongest answer: One consent store as the source of truth, purpose IDs, APIs for tag managers, and a sync into the WebView — no ad-hoc dual-write cookies

    Why it works: Consent is a distributed state problem. One store, purpose-scoped, readable by GTM and the WebView bridge.

    • One consent record, many surfaces.
    • Purpose IDs, not a boolean.
    • Tag manager and WebView read the same store.
    • No cookies before grant — including WebViews.