yoklainterview sim
ProgressHistory

Frontend Web Security Interview Questions

75 verified Frontend Web Security interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Web SecurityDifficulty 1
What is a cross-site scripting (XSS) vulnerability?
  • aA server crashing because a page sends far too many requests at once
  • bA visitor tricking a site into serving an outdated cached copy of a page
  • cAn attacker getting a victim's browser to run malicious script from a page✓
  • dA slow network connection that makes a page's own scripts load in the wrong order and fail
Explanation:XSS means attacker-controlled script executes in the victim's browser in the context of a trusted site, letting it steal cookies/tokens, read the DOM, or act as the user. It is a client-side code-execution flaw, not a server crash (a) or a caching issue (b).
Web SecurityDifficulty 2
const comment = getUserComment();   // text typed by any visitor
document.getElementById("box").innerHTML = comment;

A comment field renders each visitor's text with the code above. Why is this dangerous?
  • aA comment containing markup like <img src=x onerror=...> will be parsed and executed✓
  • binnerHTML shows only plain text, so any HTML tag in the comment crashes the page
  • cAssigning to innerHTML is not supported in modern browsers and silently fails
  • dSearch engines cannot index text set this way, but there is otherwise no real security problem here
Explanation:Assigning untrusted text to innerHTML makes the browser parse it as HTML, so an attacker can inject an image with an onerror handler (or other markup) that runs script — stored XSS. innerHTML does render HTML rather than showing it as text (b), which is exactly the danger. Use textContent, or sanitize if HTML is genuinely required.
Web SecurityDifficulty 2
What distinguishes a stored XSS from a reflected XSS?
  • aStored XSS only works over plain HTTP, while reflected XSS needs an HTTPS connection
  • bReflected XSS can read cookies and tokens, whereas stored XSS is unable to touch them
  • cStored XSS executes on the server side, whereas reflected XSS executes in the browser
  • dStored XSS is saved server-side and shown to later visitors; reflected XSS bounces back in the response to a crafted request✓
Explanation:Stored (persistent) XSS lives in the app's data — a comment, a profile field — and fires for everyone who loads it; reflected XSS is not stored but echoed straight back from a single crafted request or link. Both run in the browser (c) and both can read cookies (b); the axis is where the payload lives, not what it can do.
Web SecurityDifficulty 2
const name = getQueryParam("name");   // attacker controls the URL
// Option A:
box.innerHTML = "Hello " + name;
// Option B:
box.textContent = "Hello " + name;

Both lines show the visitor's name. Which is the safe choice for untrusted input, and why?
  • aOption A, because innerHTML automatically escapes any dangerous characters on its own
  • bOption B, because textContent inserts the value as literal text, not as HTML✓
  • cEither one, since a URL query parameter cannot contain real HTML tags
  • dNeither; the only safe way is to disable JavaScript for the whole page
Explanation:textContent sets the node's text and never parses markup, so <script> becomes visible characters instead of executing. innerHTML parses the string as HTML, so an attacker-controlled name can inject script; it does not auto-escape (a). URL parameters can absolutely carry HTML/JS payloads (c).
Web SecurityDifficulty 1
Why should user-provided values be escaped (output-encoded) before being placed into a page's HTML?
  • aSo characters like < and > are shown as text instead of being read as HTML tags✓
  • bSo the page loads faster because the browser then has less HTML to parse
  • cSo the values are compressed and take up less space in the HTTP response
  • dSo screen readers can pronounce the special characters more accurately
Explanation:Escaping turns HTML-significant characters (<, >, &, quotes) into harmless entities, so the browser renders them as text and cannot be tricked into treating injected markup as real tags — the core defense against XSS. It is about safety, not performance (b) or size (c).
Web SecurityDifficulty 2
Most UI frameworks offer a special way to insert a raw HTML string into the DOM (for example a "render raw HTML" binding). What is the main security concern when using such a feature with data that came from users?
  • aIt disables the browser's back button for as long as the raw HTML stays on screen
  • bIt always makes the component re-render noticeably slower than normal bindings do
  • cIt converts the incoming HTML to plain text, so the intended formatting is lost
  • dIt bypasses the framework's automatic escaping, so any script in the data can run✓
Explanation:Frameworks escape interpolated values by default; the raw-HTML binding deliberately turns that off and injects the string as markup, so feeding user data into it reintroduces XSS unless the HTML is sanitized first. It does not convert HTML to text (c) — that would actually be the safe, default behavior.

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview