Sample questions
Security Web VulnerabilitiesDifficulty 1
A comment submitted by a user is displayed back to other visitors unchanged. If the comment contains a <script> tag, the browser executes it for everyone who views the page. What kind of vulnerability is this?
- aStored XSS, saved and replayed to later viewers✓
- bSQL injection, script parsed as a database command
- cCSRF, a request forged on the victim's behalf
- dSSRF, the server contacting an internal resource
Explanation:Because the payload is written to storage (e.g. a database) and rendered unescaped for future visitors, it is stored (persistent) XSS — the classic case is a comment or profile field that reflects unsanitized HTML back to other users.
Security Web VulnerabilitiesDifficulty 2
A search page renders the query string directly into the heading, e.g. <h1>Results for: {query}</h1>, without encoding. An attacker sends a victim a crafted link containing a script payload in that query parameter; the script runs only when the victim clicks the link. Which XSS variant is this?
- aStored XSS, saved permanently in the database
- bReflected XSS, fires only via a clicked link✓
- cDOM-based XSS, never touches the server at all
- dBlind XSS, attacker never sees any response
Explanation:The payload lives only in the request (the URL/query string) and is immediately reflected back in the response — nothing is stored. It requires a per-victim crafted link, which is the hallmark of reflected XSS.
Security Web VulnerabilitiesDifficulty 2
A page's client-side JavaScript reads a value from location.hash and inserts it into the DOM via innerHTML, without that value ever being sent to or processed by the server. What distinguishes this from stored or reflected XSS?
- aIt requires direct database access to exploit
- bOnly an authenticated administrator can trigger it
- cThe vulnerable flow stays entirely in the browser✓
- dIt is not exploitable unless the site avoids cookies
Explanation:DOM-based XSS is defined by the source-to-sink flow happening entirely in browser JavaScript (e.g. location.hash → innerHTML). No server round-trip is involved, unlike stored (persisted server-side) or reflected (echoed by the server) XSS.
Security Web VulnerabilitiesDifficulty 1
A developer renders a user-supplied comment with element.innerHTML = comment;. Why does this expose the page to XSS?
- a
innerHTML is slower than textContent, a timing side channel - bThe browser refuses to render strings set via
innerHTML - c
innerHTML only accepts same-origin data by design - d
innerHTML parses the string as markup, so scripts execute✓
Explanation:innerHTML re-parses its argument as HTML. Any <script>, <img onerror=...>, or similar markup in comment becomes live DOM the browser executes, rather than inert text.
Security Web VulnerabilitiesDifficulty 2
Two versions render the same untrusted comment value: Version 1 uses element.textContent = comment, Version 2 uses element.innerHTML = comment. Why is Version 1 safe from XSS while Version 2 is not?
- a
textContent shows the string as literal text, never parsed✓ - b
textContent automatically strips SQL keywords from strings - c
textContent blocks all network requests from the page - d
textContent silently encrypts the string before display
Explanation:textContent never treats its input as markup — angle brackets and quotes are displayed as visible characters, so there is no way for comment to introduce an executable element.
Security Web VulnerabilitiesDifficulty 1
What is SQL injection, at its core?
- aOverwhelming a database with too many connections
- bUntrusted input concatenated directly into a query string✓
- cA database server crashing on a malformed packet
- dA misconfigured database allowing anonymous backup access
Explanation:SQL injection happens when user-controlled data is mixed into the text of a query rather than kept separate as data, so specially crafted input can change what the query actually does.