How to Confirm XSS When CSP Allows Only Same-Domain Scripts?

312-50v12 By islever Editorial Last updated Oct 17, 2026

Hacking Web Applications

Short answer

A Use a script hosted on the application's own domain, since the CSP permits same-domain scripts, to confirm the XSS execution.

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?

Utilize a script hosted on the application's domain to test the form Correct Answer
Try to disable the CSP to bypass script restrictions
Inject a benign script inline to the form to see if it executes
Load a script from an external domain to test the vulnerability

Key Takeaways

The exam tests whether you adapt an XSS proof-of-concept to the site's CSP; the trap is treating a benign inline payload as valid confirmation even though inline scripts are explicitly blocked.

This question tests how to validate an XSS finding when a strict Content Security Policy blocks inline and external scripts but permits same-origin sources. It establishes that the ethical hacker should use an application-hosted script to confirm execution rather than attempting a CSP bypass.

Common mistake: Choosing inline injection because it is the usual first XSS probe; under this CSP the browser blocks it, so the failed execution does not confirm or disprove the vulnerability.

Expert Analysis

Why the Answer Is Correct

Option A follows the CSP that the application actually enforces: inline scripts and external domains are disallowed, but scripts from the application's own domain are permitted. To confirm the XSS, the tester must therefore use a same-origin script that the browser will load and execute if the input reaches an executable context. This validates the vulnerability without trying to defeat the security control, keeping the test closer to real exploitable conditions. As insaniunt noted, the approach is valid because "the CSP allows scripts from the application's own domain."

Why the Other Options Are Wrong

Option C is the intuitive first probe, but inline scripts are explicitly blocked by this CSP, so a benign inline payload will not execute and cannot confirm the flaw. Option D fails for the same reason because external-domain scripts are disallowed by the policy. Option B is not a confirmation step: disabling CSP changes the application's security posture, may exceed the assessment scope, and does not prove that the original input handling is vulnerable. HackerTom's question about trying a simple test box reflects the common inline-first habit, but CSP makes that test ineffective here.

Community Comment Notes

Most commenters support A because it matches the policy's only permitted script source. HackerTom asked, "Isn't the first step always trying some type of hello world or test box?" which captures why C attracts votes, though that instinct breaks under a blocking CSP. LordXander suggested B could also apply but leaned toward A; the stronger reading is that A is direct validation while B is a bypass action that does not confirm the XSS under the stated conditions.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a CSP is described, first identify which source expressions are allowed and select the test payload that fits that allowlist. Do not choose inline or external-script tests that the policy explicitly blocks, and avoid disabling CSP as a shortcut because it does not validate the original vulnerability.

Frequently Asked Questions

Why is an inline benign script not enough to confirm the XSS under this CSP?

The CSP disallows inline scripts, so the browser blocks the payload before execution; a blocked probe cannot prove the input is exploitable.

Can a same-domain hosted script still validate the 'Contact Us' XSS?

Yes. If the injected input causes the allowed same-origin script to execute, that demonstrates script execution under the stated CSP and confirms the vulnerability.

More 312-50v12 FAQ →

Community Votes

50%

25%

50% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

insaniunt 👍 2 Answered A

A. Utilize a script hosted on the application's domain to test the form Since the CSP allows scripts from the application's own domain, using a script hosted on the same domain would be a valid and ethical way to confirm the XSS vulnerability. This approach aligns with the permitted behavior of the CSP and helps the ethical hacker assess whether the lack of proper user input validation in the 'Contact Us' form leads to the execution of scripts from the same domain.
HackerTom 👍 1 Answered C

Any idea why this wouldn't be C? Isn't the first step always trying some type of hello world or test box?
LordXander 👍 1 Answered B

Well, B could be an option however also A. A is more applicable for an insider threat
[Removed] 👍 1

Could someone please validate this information
[Removed] 👍 1

Team can you confirm if this is accurate

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

← Back to 312-50v12 Study Guide