While testing a web application, you notice it accepts HTML input and displays it on a webpage. What additional steps should you take to confirm an XSS vulnerability?

Question

Options

• AUse a network analyzer to capture packets
• BInject <img src="x" onerror="alert('XSS')"> and observe the behavior
• CEnable JavaScript in the browser
• DCheck server logs for unusual activity

• A
  6% (3)
• B
  79% (38)
• C
  13% (6)
• D
  2% (1)

Explanation

Injecting <img src="x" onerror="alert('XSS')"> is the definitive confirmation step because it tests whether the application executes injected scripts, not just accepts HTML - the onerror handler fires JavaScript when the browser can't load the image, producing a visible alert that proves code execution occurred in the victim's browser context.

Why the distractors are wrong:

• A (network analyzer): Packet capture shows data in transit but doesn't tell you whether the browser executes injected scripts - XSS is a client-side execution flaw, not a transmission flaw.
• C (enable JavaScript): JavaScript is typically already enabled; toggling it doesn't confirm a vulnerability exists in the application - it's a browser setting, not a test.
• D (server logs): XSS payloads execute on the client side, so server logs won't show script execution - you'd only see the initial HTTP request, not whether the browser ran injected code.

Memory tip: Think "See the XSS to confirm XSS." You need an observable, in-browser trigger - the classic alert() payload gives you a pop-up you can see, which is why it's the go-to proof-of-concept in security testing. If the dialog appears, the browser executed your code.

No community discussion yet for this question.