Offensive Security OSWE Practice Test

OSWE practice test: what's covered

• White-box web exploitation
• Auth bypass
• RCE chains

Free OSWE sample questions

1. During a white-box review of a Node.js app, a reviewer wants to enumerate every endpoint that lacks an authorization check. Which code-review approach most reliably surfaces this class of defect?

   • A. Map each route handler to its authentication/authorization middleware and flag any route reachable without a verified session or role check
   • B. Run the application and click through the UI as a logged-in user to confirm pages load correctly
   • C. Search the templates for hardcoded HTML comments that mention internal admin features
   • D. Measure the response time of each endpoint and treat the slowest ones as the highest risk
   Show answer

   Correct: A. Building a route-to-authz matrix is the canonical secure-review technique because missing access control is invisible at runtime when you are already authenticated. Clicking through the UI is incorrect because broken-access-control endpoints often are not linked in the UI at all. Reading HTML comments and timing responses do not establish whether an authorization gate exists, so they cannot prove a route is protected.

2. A reviewer finds a handler that executes `eval(req.body.expression)` on attacker-supplied input. Which remediation removes the remote-code-execution risk while preserving the feature?

   • A. Wrap the eval call in a try/catch block so thrown errors are logged and suppressed
   • B. Replace eval with a constrained expression parser or allowlisted operation table that never executes arbitrary code strings
   • C. HTML-encode the expression before passing it into eval to neutralize script tags
   • D. Move the eval call behind an authentication check so only logged-in users reach it
   Show answer

   Correct: B. eval on user input is direct RCE, and the only safe fix is to stop interpreting the input as code by using a sandboxed parser or an explicit allowlist of operations. A try/catch is incorrect because the code still executes before any error. HTML-encoding addresses XSS, not server-side execution, so it is the wrong control. Authentication alone is insufficient because any authenticated user, including a compromised one, still gets code execution.

3. A PHP file builds an include path as `include($_GET['page'] . '.php');`. A defender reviewing this code should classify it as which vulnerability, and what is the correct fix?

   • A. Cross-site scripting; the fix is to set the HttpOnly flag on the session cookie
   • B. Open redirect; the fix is to validate that the Location header points to the same host
   • C. Local/remote file inclusion; the fix is to map the parameter to an allowlist of known view names instead of concatenating it into a path
   • D. SQL injection; the fix is to switch the database driver to use prepared statements
   Show answer

   Correct: C. Concatenating user input into an include path is the textbook file-inclusion sink, and replacing dynamic paths with a fixed allowlist (a switch or whitelist map) is the durable remediation. XSS and its HttpOnly fix are incorrect because the bug is server-side file loading, not browser script. Open redirect is unrelated to include(). SQL injection and prepared statements do not apply because no query is involved here.

4. While auditing front-end code, a reviewer sees `element.innerHTML = location.hash.substring(1)` executed on page load. Which secure-coding fix eliminates the DOM-based XSS sink?

   • A. Assign the value using textContent (or a sanitizer that strips active markup) instead of innerHTML so the data is never parsed as HTML
   • B. Add a server-side WAF rule that blocks the string 'onerror' in query parameters
   • C. URL-encode the entire page URL before the JavaScript runs on the client
   • D. Set a Content-Length header so the browser truncates oversized fragments
   Show answer

   Correct: A. DOM XSS happens because attacker-controlled data flows into an HTML-parsing sink, so writing to textContent (or sanitizing) breaks the sink and is the correct fix. A WAF rule is incorrect because the fragment after # is never sent to the server and cannot be inspected there. Encoding the URL on the client does not change how innerHTML parses the assigned string. A Content-Length header has no effect on client-side DOM parsing.

5. A reviewer notes that `path.join(uploadDir, req.query.file)` is later passed to fs.readFile, and `req.query.file` may contain '../' sequences. Which secure-coding controls correctly prevent path traversal here? (Choose TWO)

   • A. Resolve the final path and verify it still starts with the intended base directory before any file access
   • B. Strip or reject inputs containing path separators and parent-directory tokens, mapping requests to an allowlist of known filenames
   • C. Trust path.join to confine the result because it normalizes the path automatically
   • D. Convert the filename to uppercase before joining it to the base directory
   • E. Disable directory listing on the web server so the upload folder cannot be browsed
   Show answer

   Correct: A and B. Canonicalizing with path.resolve and asserting the result is inside the base directory, plus allowlisting filenames, are the two controls that actually jail file access. Trusting path.join is incorrect because it normalizes but does not confine; path.join(base, '../../etc/passwd') escapes the base. Uppercasing the filename does nothing to remove traversal sequences. Disabling directory listing is unrelated because the read happens through application code, not directory browsing.

Last updated: 2026-10-19

OSWE practice test FAQ

Related practice tests

• Offensive Security OSCP practice test
• Offensive Security OSDA practice test
• Offensive Security OSEP practice test