nerdexam
EC-Council

312-50V12 · Question #263

An ethical hacker is testing a web application of a financial firm. During the test, a 'Contact Us' form's input field is found to lack proper user input validation, indicating a potential…

The correct answer is A. Utilize a script hosted on the application's domain to test the form. To confirm the XSS vulnerability while respecting the Content Security Policy (CSP), the hacker should utilize a script hosted on the application's own domain, as this is the only script source explicitly permitted by the CSP.

Submitted by jordan8· Mar 4, 2026Web Application Hacking

Question

An ethical hacker is testing a web application of a financial firm. During the test, a 'Contact Us' form's input field is found to lack proper user input validation, indicating a potential Cross-Site Scripting (XSS) vulnerability. However, the application has a stringent Content Security Policy (CSP) disallowing inline scripts and scripts from external domains but permitting scripts from its own domain. What would be the hacker's next step to confirm the XSS vulnerability?

Options

  • AUtilize a script hosted on the application's domain to test the form
  • BTry to disable the CSP to bypass script restrictions
  • CInject a benign script inline to the form to see if it executes
  • DLoad a script from an external domain to test the vulnerability

How the community answered

(41 responses)
  • A
    76% (31)
  • B
    12% (5)
  • C
    5% (2)
  • D
    7% (3)

Why each option

To confirm the XSS vulnerability while respecting the Content Security Policy (CSP), the hacker should utilize a script hosted on the application's own domain, as this is the only script source explicitly permitted by the CSP.

AUtilize a script hosted on the application's domain to test the formCorrect

The application's Content Security Policy (CSP) is configured to permit scripts originating from its own domain. By injecting a script tag that references a script hosted on the application's domain, the ethical hacker can bypass the CSP's restrictions against inline and external scripts and successfully confirm the XSS vulnerability if input validation is indeed lacking.

BTry to disable the CSP to bypass script restrictions

An ethical hacker cannot disable a server-configured Content Security Policy (CSP) through a client-side injection into an input field; CSP is a security header set by the server, enforced by the browser.

CInject a benign script inline to the form to see if it executes

The Content Security Policy (CSP) explicitly disallows inline scripts, meaning any attempt to inject a script directly within the HTML markup would be blocked by the browser, preventing execution.

DLoad a script from an external domain to test the vulnerability

The Content Security Policy (CSP) explicitly disallows scripts loaded from external domains, meaning the browser would block any attempt to execute a script hosted outside the application's origin.

Concept tested: Content Security Policy (CSP) bypass techniques for XSS

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Topics

#XSS vulnerability#Content Security Policy (CSP)#CSP bypass#same-domain script execution

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full 312-50V12 Practice