", "'; DROP TABLE users;--", "javascript:alert(1)", "" ], answer: 0, rationale: "A simple script tag is the clearest proof of execution when input is reflected into HTML content. The other options depend on specific contexts or attributes and are less direct for an initial confirmation." }, { id: 2, domainCode: "1.0", domainName: "Cross-Site Scripting Introduction and Discovery", question: "During testing, user-supplied data is inserted into an existing JavaScript string as part of a page script. Which payload is the best starting point to break out of the string safely and test for XSS?", options: [ "“, “\”;alert(1);//”, ““, “javascript:alert(1)” ], answer: 1, rationale: “When input is placed inside a JavaScript string, closing the string and commenting out the remainder is the most relevant first test. This helps determine whether the context is exploitable before trying more complex payloads.” }, { id: 3, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A search feature reflects the submitted term inside an HTML attribute value such as value=\”…\”. What is the most important first step to assess whether this may lead to XSS?”, options: [ “Test whether angle brackets are encoded in the response”, “Determine whether the attribute is quoted and whether quote characters are escaped”, “Check whether the page uses HTTPS”, “Send a very large payload to force a server error” ], answer: 1, rationale: “Attribute context is primarily affected by quote handling and escaping. Knowing whether the attribute is quoted and whether quotes are encoded determines whether the attacker can break out of the attribute.” }, { id: 4, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A target page sanitizes angle brackets but reflects apostrophes and quotation marks inside an event handler attribute. Which type of payload is most likely to succeed?”, options: [ “A payload that breaks out of the attribute and injects a new handler”, “A payload that relies only on a script tag in the HTML body”, “A payload that uses SQL comment syntax”, “A payload that requires file upload capability” ], answer: 0, rationale: “If angle brackets are blocked but quotes are not, the attacker may be able to escape the current attribute and inject a new event handler or similar executable attribute-based payload.” }, { id: 5, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which response behavior is the strongest evidence of stored XSS rather than reflected XSS?”, options: [ “The payload appears only after the user refreshes the page”, “The payload is executed only in a private browsing window”, “The payload is saved in the application and later executes when another user views the content”, “The payload is blocked by the browser’s pop-up blocker” ], answer: 2, rationale: “Stored XSS is characterized by persistence: the payload is saved server-side and later delivered to other users. Reflection alone without persistence indicates a different XSS class.” }, { id: 6, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A tester wants to confirm whether a parameter is vulnerable to DOM-based XSS without sending the payload to the server. What is the best initial approach?”, options: [ “Analyze client-side JavaScript for sources and sinks that use the parameter”, “Upload a malicious HTML file to the server”, “Search for SQL injection errors in server responses”, “Request the page over FTP instead of HTTP” ], answer: 0, rationale: “DOM-based XSS often occurs entirely in client-side code, so reviewing sources and sinks in JavaScript is the correct first step. This identifies unsafe DOM manipulation before active exploitation.” }, { id: 7, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which of the following is the best example of a safe, low-impact XSS proof-of-concept during authorized testing?”, options: [ “A payload that deletes user accounts to demonstrate impact”, “A payload that redirects all users to an external phishing site”, “A payload that displays a harmless alert box or simple proof marker”, “A payload that attempts to exfiltrate session cookies” ], answer: 2, rationale: “A harmless proof marker demonstrates execution while minimizing risk. Ethical testing should avoid destructive actions, credential theft, or unsolicited redirection.” }, { id: 8, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “An application encodes < and > but leaves single quotes unencoded in a URL parameter that is later inserted into an inline event handler. What is the most likely reason the application may still be vulnerable?”, options: [ “Single quotes can terminate the current JavaScript or attribute context”, “The browser will automatically reject all encoded content”, “Angle bracket encoding alone prevents every possible XSS vector”, “Inline event handlers cannot execute JavaScript” ], answer: 0, rationale: “Encoding only angle brackets is insufficient when the payload lands in a quoted attribute or JavaScript context. Unescaped quotes can break out of the current context and allow execution.” }, { id: 9, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A page uses location.hash in JavaScript to update part of the DOM. Which finding would most strongly suggest a DOM XSS sink?”, options: [ “The hash value is compared to a static string”, “The hash value is passed to innerHTML without sanitization”, “The hash value is stored in a cookie only”, “The hash value is used to change the page title safely” ], answer: 1, rationale: “Passing attacker-controlled data from location.hash into innerHTML is a classic unsafe sink. This can allow script execution entirely in the browser without a server-side reflection.” }, { id: 10, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which issue most commonly enables XSS in modern single-page applications when developers trust data from the URL fragment or browser storage?”, options: [ “Improper client-side sanitization before DOM insertion”, “Weak database indexing”, “Missing DNSSEC records”, “Improper TLS certificate chain order” ], answer: 0, rationale: “Client-side trust of untrusted sources such as the URL fragment or local storage frequently leads to unsafe DOM insertion. This is a common cause of modern XSS in SPAs.” }, { id: 11, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A tester observes that input is reflected inside a script block as JSON data and then parsed by client-side code. Which testing concern is most relevant?”, options: [ “Whether the value can escape the JSON string and break JavaScript syntax”, “Whether the response body includes a file download header”, “Whether the page supports IPv6”, “Whether the application uses compression” ], answer: 0, rationale: “When data is embedded in JSON or a script block, the key question is whether the attacker can break out of the string or script context. This determines whether JavaScript execution is possible.” }, { id: 12, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which scenario is the best indicator of a potential second-order XSS issue?”, options: [ “Input is immediately executed on the same page after submission”, “Input is stored safely and never rendered again”, “Input is stored in the database and later rendered in an administrative panel without proper encoding”, “Input is blocked by a WAF before reaching the server” ], answer: 2, rationale: “Second-order XSS occurs when malicious input is stored first and later rendered in a dangerous context. The execution happens during a later page view rather than immediately after submission.” }, { id: 13, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “When testing for XSS in a search result page, which observation best suggests that the application is escaping output correctly?”, options: [ “The payload is rendered as plain text with special characters encoded”, “The browser displays a blank page”, “The response time increases slightly”, “The server returns HTTP 200 OK” ], answer: 0, rationale: “Proper output encoding should cause attacker-controlled characters to be displayed as text, not interpreted as markup or script. Rendering the payload literally indicates the application is likely escaping output correctly.” }, { id: 14, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A form field is inserted into HTML content after server-side sanitization, but the application later uses the same value inside a different context. What is the main lesson for XSS assessment?”, options: [ “Sanitization is always universal across every output context”, “Each output context must be evaluated separately”, “One successful test proves all inputs are safe”, “Only POST parameters can be dangerous” ], answer: 1, rationale: “A value safe in one context may be unsafe in another, such as HTML text versus JavaScript or an attribute. XSS testing must always consider the exact output context.” }, { id: 15, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which payload is most appropriate when testing whether user input is inserted into an unquoted HTML attribute?”, options: [ “A payload that uses spaces to add a new attribute after breaking out of the value”, “A payload that only targets SQL syntax errors”, “A payload that uploads a compiled executable”, “A payload that depends on browser extensions” ], answer: 0, rationale: “Unquoted attributes are often exploitable by injecting whitespace and a new attribute or handler. This is a classic and context-specific test for attribute-based XSS.” }, { id: 16, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A developer claims the application is safe because it filters the word ‘script’. Why is this defense insufficient?”, options: [ “XSS can be delivered only with the literal word script”, “Attackers can use alternate tags, event handlers, or context breaks”, “Filtering one keyword prevents all browser-based attacks”, “The browser refuses to parse HTML without that keyword” ], answer: 1, rationale: “Blocking a single keyword is not a reliable defense because XSS can be achieved through many other elements, attributes, and context-breaking techniques. Robust output encoding and context-aware escaping are required.” }, { id: 17, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which testing result most strongly suggests that a payload is being processed in a JavaScript context rather than in plain HTML?”, options: [ “The payload appears inside the page source but not on screen”, “The payload changes the page background color using CSS”, “The payload is reflected inside a quoted string in an inline script”, “The payload is returned with a 404 status code” ], answer: 2, rationale: “A quoted string inside an inline script indicates JavaScript context, which has different escape requirements from HTML text. This is a common clue when identifying DOM or reflected XSS opportunities.” }, { id: 18, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “A tester wants to check whether a parameter is vulnerable in multiple contexts across the same application. Which approach is most effective?”, options: [ “Test only the login page because it is usually the most important”, “Reuse a single payload without considering the output context”, “Map where the input appears and test each rendering context separately”, “Assume any encoded response means the entire application is safe” ], answer: 2, rationale: “A single input may appear in different sinks with different escaping rules. Mapping each rendering context is the best way to find both reflected and context-specific XSS issues.” }, { id: 19, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which browser-side behavior is most helpful for confirming that an XSS proof-of-concept executed successfully during testing?”, options: [ “The page’s favicon changes automatically”, “A harmless alert dialog or visible proof marker appears as expected”, “The site returns a successful login banner”, “The browser downloads the page source” ], answer: 1, rationale: “A visible proof marker such as an alert dialog confirms execution without causing harm. This is the standard low-risk confirmation method in authorized assessments.” }, { id: 20, domainCode: “1.0”, domainName: “Cross-Site Scripting Introduction and Discovery”, question: “Which statement best describes the primary goal when discovering XSS during an authorized assessment?”, options: [ “Obtain persistent access by stealing credentials whenever possible”, “Confirm a browser-executable code path and document the impact safely”, “Trigger the maximum number of alerts on the target system”, “Bypass all authentication controls through brute force” ], answer: 1, rationale: “The goal is to verify that attacker-controlled input reaches an executable browser context and to document the risk responsibly. Safe validation and clear reporting are more important than destructive exploitation.” } ] }); });

Author

  • Security Practice Test Editorial Team
    : Author

    Security Practice Test Editorial Team is the expert content team at SecurityPracticeTest.com dedicated to producing authoritative cybersecurity certification exam-prep resources. We create comprehensive practice tests, study materials, and exam-focused content for top security certifications including CompTIA Security+, SecurityX, PenTest+, CISSP, CCSP, SSCP, Certified in Cybersecurity (CC), CGRC, CISM, SC-900, SC-200, AZ-500, AWS Certified Security - Specialty, Professional Cloud Security Engineer, OSCP+, GIAC certifications, CREST certifications, Check Point, Cisco, Fortinet, and Palo Alto Networks exams. Our content is developed through careful review of official exam objectives, cybersecurity knowledge domains, and practical job-relevant concepts to help learners build confidence, strengthen understanding, and prepare effectively for certification success.