I85PREP
⌘ K
CISP-PTE Penetration Testing Engineer study materials
CISP-PTE Penetration Testing Engineer study resources

CISP-PTE Penetration Testing Engineer practice questions

One question at a time. Build your CISP-PTE Penetration Testing Engineer understanding.

First 50 of 190 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Web application and data-protection foundations

In HTTP semantics, which listed method is defined as safe and idempotent and requests retrieval rather than a state-changing operation?

  1. GET Correct answer.
  2. POST
  3. PATCH
  4. CONNECT

Explanation

GET has safe retrieval semantics and is idempotent with respect to the intended effect. Incidental effects such as access logging can still occur; safety does not mean the implementation performs no state change anywhere. State-changing application actions should use an appropriate method and actual authorization/CSRF protections.

Question 2Web application and data-protection foundations

A web application echoes the HTTP Host header into password-reset links. What is the most direct defensive control?

  1. Trust Host whenever TLS is used
  2. Allow any Host as long as the path is allowlisted
  3. Disable HTTP/1.1 Host checking at the reverse proxy
  4. Ignore the request Host and generate links from a server-side configured canonical domain Correct answer.

Explanation

Host header poisoning works when the application treats an attacker-controlled Host as the authority for absolute URLs. Password-reset and other email links must be built from a configured canonical domain (or a strictly validated allowlist of hosts), not from the raw header.

Question 3Web application and data-protection foundations

Which HTTP status code tells clients and caches that the resource has permanently moved to a new URI and that future requests should use that URI?

  1. 302 Found
  2. 301 Moved Permanently Correct answer.
  3. 304 Not Modified
  4. 307 Temporary Redirect

Explanation

301 Moved Permanently signals a durable change of URI and is commonly cached. Using 301 for a temporary relocation can send users and crawlers to the wrong place long after the original URL should have been restored.

Question 4Web application and data-protection foundations

Which response header primarily tells the user agent how to interpret the message body, including the media type used for rendering and sniffing decisions?

  1. Accept
  2. ETag
  3. Content-Type Correct answer.
  4. Location

Explanation

Content-Type declares the representation's media type (and often charset). Incorrect or missing Content-Type, especially when user-controlled data is returned, can cause browsers to treat JSON or text as HTML and create a cross-site scripting path.

Question 5Web application and data-protection foundations

A reverse proxy and origin disagree about whether a request is framed by Content-Length or Transfer-Encoding. What class of issue should a tester report, and what is the primary mitigation?

  1. Clickjacking; set X-Frame-Options only
  2. HTTP request smuggling; normalize or reject ambiguous requests at a single HTTP parser Correct answer.
  3. Open redirect; allowlist Location hosts
  4. Cache poisoning via Vary; disable caching entirely

Explanation

Conflicting Content-Length and Transfer-Encoding handling is the classic HTTP request-smuggling condition: front-end and back-end desynchronize on request boundaries. Defense is to use one consistent parser, reject ambiguous messages, and disable conflicting length encodings rather than trying to interpret both.

Question 6Web application and data-protection foundations

What security properties does HTTPS (HTTP over TLS) primarily add compared with plaintext HTTP?

  1. Confidentiality and integrity of the HTTP bytes in transit, plus server authentication Correct answer.
  2. Automatic protection against SQL injection and XSS
  3. Guaranteed authorization of every application user
  4. Elimination of CSRF because cookies are no longer sent

Explanation

TLS authenticates the server (when certificates are validated), encrypts the channel, and protects integrity of the HTTP request and response in transit. It does not fix application-layer injection, access control, or CSRF; cookies are still sent on HTTPS origins.

Question 7Web application and data-protection foundations

An authenticated page containing a session token in HTML is served with Cache-Control: public. What is the main risk?

  1. The browser will refuse to store cookies
  2. TLS will be downgraded automatically
  3. Shared caches may store and later serve another user's authenticated content Correct answer.
  4. CSRF tokens become unguessable

Explanation

public allows shared caches (proxies, CDNs) to store the response. Authenticated or personalized pages should use private or, for highly sensitive bodies, no-store, so one user's page is not reused for another.

Question 8Web application and data-protection foundations

What is the primary, durable mitigation for SQL injection in application code?

  1. Blacklisting the words SELECT and UNION in a WAF only
  2. Parameterized queries (prepared statements) that bind user data separately from SQL Correct answer.
  3. Hiding detailed database errors from users and doing nothing else
  4. Encrypting the database at rest

Explanation

Parameterized queries send SQL structure and values on separate channels so user input cannot change the statement's meaning. Encryption at rest, error hiding, and WAF signatures are supporting controls; they do not make concatenated SQL safe.

Question 9Web application and data-protection foundations

An application never returns database errors, but a boolean condition in a search parameter consistently changes response time or page content. How should this be classified?

  1. Blind SQL injection indicator requiring parameterized-query remediation Correct answer.
  2. Reflected XSS because the page content changed
  3. CSRF because the request used a cookie
  4. A safe search feature because no stack trace was shown

Explanation

Blind SQL injection is identified when injected boolean or time-based conditions change behavior without verbose SQL errors. The fix is still parameterization (and least-privilege DB accounts), not merely hiding errors.

Question 10Web application and data-protection foundations

A filename supplied by a user is concatenated into a shell command that runs an image converter. Which issue is this, and what is the preferred fix?

  1. SQL injection; switch to MySQL
  2. CSRF; add a SameSite cookie
  3. Open redirect; allowlist URLs
  4. OS command injection; avoid the shell and call a safe API with a validated argument list Correct answer.

Explanation

Command injection occurs when untrusted data reaches a shell or command interpreter. The robust control is not to invoke a shell at all: use a process API with a fixed executable and an allowlisted argument list, plus strict filename validation.

Question 11Web application and data-protection foundations

User input is stored with parameterization, then later copied into a different dynamic SQL statement without binding. What is this pattern called?

  1. DOM-based XSS
  2. Stored CSRF
  3. Second-order SQL injection Correct answer.
  4. HTTP response splitting

Explanation

Second-order SQL injection is stored, apparently neutralized input that becomes dangerous when a later code path concatenates it into SQL. Every query, including batch jobs and admin reports, must parameterize.

Question 12Web application and data-protection foundations

Which observation is the strongest initial indicator of a SQL injection flaw during testing?

  1. The site uses HTTPS
  2. Database error text or unexpected row changes appear when a single input is varied Correct answer.
  3. The login form has an autocomplete attribute
  4. The server banner includes Apache

Explanation

SQL injection is indicated when user-controlled input changes query behavior: database errors, altered result sets, or boolean/time differentials tied to that input. Transport, autocomplete, and server banners are unrelated to query construction.

Question 13Web application and data-protection foundations

Untrusted input is placed into an LDAP search filter. What is the appropriate defensive approach?

  1. Escape or allowlist filter metacharacters and avoid building filters from raw input Correct answer.
  2. Enable directory listing on the web server
  3. Switch the application cookie to SameSite=None
  4. Grant the bind account Domain Admin rights so searches always succeed

Explanation

LDAP injection uses filter metacharacters to change search meaning or bypass authentication. Defense is context-aware escaping or allowlisting, plus a least-privilege bind account. Widening directory rights makes a successful injection worse.

Question 14Web application and data-protection foundations

A team says an ORM makes SQL injection impossible. When is that claim false?

  1. Always false, because ORMs cannot issue SELECT statements
  2. Only when the database is MySQL
  3. Only when TLS is disabled
  4. When developers pass concatenated or raw SQL strings through the ORM instead of bound parameters Correct answer.

Explanation

ORMs prevent many injection cases when they generate parameterized SQL. Native-query APIs, string-built fragments, and order-by/limit concatenation still create SQL injection. The control is parameterization of every query, including those issued via an ORM.

Question 15Web application and data-protection foundations

Why is JavaScript validation in the browser not an adequate defense against injection?

  1. Browsers cannot send HTTP POST bodies
  2. JavaScript always disables cookies
  3. Attackers can send requests that bypass the browser entirely, so the server must validate and parameterize Correct answer.
  4. Server-side parameterized queries are forbidden if JavaScript exists

Explanation

Client-side checks improve usability but are not a trust boundary. Any client can be modified or skipped with an intercepting proxy or custom HTTP client. Injection defenses must run on the server with parameterized queries and allowlists.

Question 16Web application and data-protection foundations

A stored procedure builds SQL by concatenating a user-supplied table name. What is the correct assessment?

  1. Stored procedures are immune to SQL injection by definition
  2. The procedure is still injectable; identifiers must be allowlisted and values bound as parameters Correct answer.
  3. Only Oracle procedures can be injectable, which is out of PTE scope
  4. Disabling verbose errors fully remediates the issue

Explanation

Stored procedures help only when they use parameters as data, not as concatenated SQL. Dynamic identifiers (table/column names) cannot be bound as values; they require a strict server-side allowlist.

Question 17Web application and data-protection foundations

A comment field stores a visitor's input and later shows it to every other visitor as HTML. Which XSS type is this?

  1. Stored (persistent) XSS Correct answer.
  2. Reflected XSS only
  3. DOM XSS only, because a database is involved
  4. CSRF, because other users are affected

Explanation

Stored XSS persists the payload on the server and executes in other users' browsers when the data is rendered unsafely. It is typically higher impact than reflected XSS because it does not require the victim to click a crafted URL.

Question 18Web application and data-protection foundations

A session cookie is marked HttpOnly. Which XSS impact does that flag prevent, and which impact remains?

  1. It prevents all XSS; no further encoding is needed
  2. It prevents CSRF; XSS becomes impossible
  3. It prevents JavaScript from reading the cookie, but XSS can still act as the user in the page Correct answer.
  4. It prevents HTML injection but not JavaScript injection

Explanation

HttpOnly stops document.cookie access, reducing session-token theft via XSS. Script running in the page can still perform actions as the user, read non-HttpOnly storage, and modify the DOM. Output encoding and CSP remain required.

Question 19Web application and data-protection foundations

What is the primary application-level control against XSS when rendering untrusted data?

  1. Relying on HTTPS alone
  2. Context-aware output encoding (and using safe APIs) for the HTML, attribute, JS, or URL context Correct answer.
  3. Disabling cookies site-wide
  4. Storing session IDs in the URL so scripts cannot see cookies

Explanation

XSS is a code-injection problem in a web context. Data must be encoded or passed through safe APIs appropriate to HTML body, attributes, JavaScript, CSS, or URLs. HTTPS and cookie changes do not encode output.

Question 20Web application and data-protection foundations

Client-side script copies a URL fragment into innerHTML without encoding. Which XSS class is this, and which control helps as defense-in-depth?

  1. Stored XSS; disable JavaScript in all browsers
  2. SQL injection; add a WAF rule for UNION
  3. Reflected XSS in a server template; HttpOnly only
  4. DOM-based XSS; avoid unsafe sinks and add a strict Content-Security-Policy Correct answer.

Explanation

DOM XSS occurs when browser script reads an untrusted source (here the fragment) and writes it to a dangerous sink such as innerHTML. Fix the script to use textContent or safe APIs; CSP script-src reduces remaining injection.

Question 21Web application and data-protection foundations

Which Content-Security-Policy directive most directly reduces the impact of injected inline script?

  1. script-src that disallows unsafe-inline and unexpected hosts Correct answer.
  2. img-src *
  3. font-src data:
  4. upgrade-insecure-requests by itself

Explanation

script-src controls which scripts may run. Disallowing unsafe-inline and limiting hosts is defense-in-depth against XSS. CSP does not replace output encoding, but it sharply cuts exploitability of many injection bugs.

Question 22Web application and data-protection foundations

Untrusted input is placed into an HTML href without allowing only http/https schemes. Why is this still an XSS risk?

  1. href values cannot execute anything in modern browsers
  2. Only CSS injection is possible in href
  3. A javascript: or data: URL can execute script when the user activates the link Correct answer.
  4. href injection is exclusively an SSRF issue on the server

Explanation

Attribute context matters. A javascript: or data: URL in href or similar handlers runs script in the page origin when followed. Encode for URL/attribute context and allowlist http/https (and relative) schemes.

Question 23Web application and data-protection foundations

How does XSS differ from CSRF?

  1. They are different names for the same cookie-theft bug
  2. XSS executes attacker-controlled script in the victim's browser; CSRF causes the victim's browser to send an unwanted authenticated request without injecting script Correct answer.
  3. CSRF requires SQL injection first; XSS does not
  4. XSS only affects APIs; CSRF only affects static files

Explanation

XSS is script injection in the origin; CSRF is a confused-deputy request using the victim's existing session. XSS can often perform any action the user can, including bypassing some CSRF defenses that sit in the page.

Question 24Web application and data-protection foundations

What is the core mechanism of classic CSRF against a cookie-authenticated site?

  1. The browser automatically attaches the victim's cookies to a cross-site request the victim did not intend Correct answer.
  2. The attacker reads the victim's HttpOnly cookie via innerHTML
  3. The server ignores TLS and falls back to FTP
  4. The attacker must first steal the CSRF token from localStorage using SQL injection

Explanation

CSRF abuses ambient authentication: cookies (or similar) are sent because the browser believes the request is for that site. Defenses include anti-CSRF tokens unbound to automatic cookies, SameSite cookies, and avoiding state changes on GET.

Question 25Web application and data-protection foundations

A site sets SameSite=Lax on its session cookie. Which cross-site request will still include that cookie?

  1. A cross-site fetch() POST from foreign JavaScript
  2. A cross-site iframe POST form
  3. A cross-site image tag GET
  4. A top-level cross-site GET navigation, such as clicking a link Correct answer.

Explanation

SameSite=Lax sends the cookie on top-level navigational GET requests but withholds it on most cross-site POSTs and embedded subresource requests. State-changing GET endpoints remain CSRF-exposed under Lax.

Question 26Web application and data-protection foundations

Why is putting a CSRF token only in a cookie, without requiring a matching token in a request header or body, a weak control?

  1. Cookies cannot be marked Secure
  2. The browser will still attach that cookie automatically on cross-site requests, so the token is not a secret the attacker lacks Correct answer.
  3. CSRF tokens are only valid for WebSocket upgrades
  4. SameSite=Strict is implied by any CSRF cookie

Explanation

A synchronizer or double-submit design works when the attacker cannot read the token and must submit it in a non-automatically-attached field (custom header or form body). A cookie-only token is sent automatically, so it does not distinguish a forged request.

Question 27Web application and data-protection foundations

Why must applications avoid changing state with GET when defending against CSRF?

  1. GET cannot carry cookies
  2. GET is always blocked by SameSite=None
  3. Cross-site GET can be triggered by a link or embedded resource without a custom header or token Correct answer.
  4. GET responses cannot include CSP

Explanation

A third-party page can cause a GET with a simple link or img/script tag. If that GET transfers money, changes email, or deletes data, CSRF succeeds even when POST would have required a token. Use safe methods for reads and protect state-changing methods.

Question 28Web application and data-protection foundations

An API reflects the request Origin in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. What is the risk?

  1. Any requesting origin can read authenticated responses in the victim's browser Correct answer.
  2. SQL injection becomes inevitable
  3. HttpOnly cookies are disabled automatically
  4. The server will refuse all POST requests

Explanation

Reflecting arbitrary Origin with credentials turns CORS into a data-theft channel: a malicious site's script can read responses using the victim's cookies. Allowlist specific trusted origins; never combine a wildcard or reflected origin with credentials.

Question 29Web application and data-protection foundations

A feature fetches a URL supplied by the user on the server and returns the response. What vulnerability class is this?

  1. Stored XSS
  2. Server-side request forgery (SSRF) Correct answer.
  3. Clickjacking
  4. Session fixation

Explanation

SSRF is the server making a request to an attacker-influenced destination. Impact includes reaching internal HTTP services and cloud instance metadata that the attacker cannot contact directly.

Question 30Web application and data-protection foundations

When hardening a server-side URL fetcher against SSRF, which destination class must be blocked even if the hostname looks public?

  1. Link-local and loopback addresses such as 169.254.169.254 and 127.0.0.1 after DNS resolution Correct answer.
  2. Any HTTPS URL on the public Internet
  3. URLs that use the GET method
  4. CDN hostnames used for static images

Explanation

After resolving DNS, the fetcher must refuse loopback, link-local, private, and metadata addresses (including 169.254.169.254 used by several clouds). Hostname allowlists that skip the resolved IP are insufficient.

Question 31Web application and data-protection foundations

An SSRF filter allowlists a hostname, then follows HTTP redirects and does not re-check the resolved IP. What bypass class should be reported?

  1. Clickjacking via X-Frame-Options
  2. Password spraying
  3. ToCTOU/DNS rebinding or redirect-to-internal targeting Correct answer.
  4. JWT algorithm none in the browser

Explanation

If validation happens on the first hostname only, a later redirect or a DNS change between check and fetch can point at an internal IP. Defense is: resolve, pin and re-validate the IP, refuse private ranges, and do not follow redirects to unvalidated hosts.

Question 32Web application and data-protection foundations

Which URL scheme should a server-side HTTP client disable if the feature only needs to retrieve web pages?

  1. https
  2. http for the documented allowlist
  3. wss for the application's own websocket
  4. file, gopher, and other non-HTTP schemes that can reach local files or unexpected services Correct answer.

Explanation

SSRF libraries that accept file, gopher, dict, or similar schemes expand impact to local files and odd services. Restrict the client to http/https, disable unused schemes, and still apply destination allowlists.

Question 33Web application and data-protection foundations

How does SSRF differ from CSRF?

  1. SSRF is a browser bug; CSRF is a DNS bug
  2. SSRF makes the server send requests to a target the attacker chooses; CSRF makes the victim's browser send requests to a site the victim is logged into Correct answer.
  3. They are identical if HTTPS is used
  4. CSRF only affects APIs; SSRF only affects FTP

Explanation

The confused deputy in SSRF is the server; in CSRF it is the victim's browser. Defenses differ: destination allowlists and no internal fetches versus anti-CSRF tokens and cookie policy.

Question 34Web application and data-protection foundations

What is the most important combination of controls for user file uploads?

  1. Allowlist of types, store outside the web root with random names, and never execute upload directories Correct answer.
  2. Trust the client Content-Type and keep original filenames in /uploads under the document root with script execution enabled
  3. Only check the file extension on the client in JavaScript
  4. Allow any file as long as it is smaller than 2 GB

Explanation

Unsafe upload plus a traversable, executable web directory is a common path to a web shell. Validate type server-side, rename, store outside the document root, serve via a non-executing handler, and authorize downloads separately.

Question 35Web application and data-protection foundations

A download parameter concatenates user input after a base directory. Which issue is this, and what is the fix?

  1. CSRF; add SameSite=None
  2. XSS; set X-XSS-Protection: 0
  3. Path traversal; canonicalize the path and reject anything outside the intended base directory Correct answer.
  4. SSRF; block 169.254.169.254 only

Explanation

Dot-dot and encoding tricks in a file path are path traversal (directory traversal). The server must resolve the real path and confirm it still starts with the authorized base, or better, map opaque IDs to files and never use raw paths.

Question 36Web application and data-protection foundations

Why is trusting the client-supplied Content-Type insufficient for upload validation?

  1. Content-Type cannot be sent over HTTPS
  2. The client fully controls that header; the server must verify magic bytes and an allowlist independently Correct answer.
  3. Browsers never send Content-Type on POST
  4. Magic-byte checks are forbidden by HTTP

Explanation

Content-Type on an upload is just another attacker-controlled field. Determine type from file signatures and a strict allowlist, then store a new name with a safe extension.

Question 37Web application and data-protection foundations

A server maps multiple extensions so that a name ending in .php.jpg is executed as PHP. What should a tester recommend?

  1. Keep multi-extension execution and rely on client-side renaming
  2. Store uploads with the original name under the scripts directory
  3. Enable directory listing so admins can spot extra extensions
  4. Disable execution in the upload location and do not map extra extensions to interpreters Correct answer.

Explanation

Handler misconfiguration that executes files based on an embedded extension is a classic upload-to-code path. Upload directories must be non-executable, extra extension mappings removed, and names rewritten to a single safe extension.

Question 38Web application and data-protection foundations

An include() or similar server construct takes a user-supplied path to load a local template. What is the issue and the preferred fix?

  1. Local file inclusion; allowlist template names and never concatenate raw paths Correct answer.
  2. CSRF; because includes are GET requests
  3. Clickjacking; set CSP style-src
  4. Open redirect; allowlist Location

Explanation

Local file inclusion (LFI) lets an attacker influence which local file is parsed or executed. Use a server-side allowlist of templates, disable remote includes, and never pass request parameters into include/require/file APIs.

Question 39Web application and data-protection foundations

A download endpoint accepts a file path or sequential ID without checking whether the authenticated user owns that object. What should be reported?

  1. Only a TLS finding
  2. Only missing SPF on email
  3. Insecure direct object reference / broken authorization on the file Correct answer.
  4. Only a missing HSTS header

Explanation

If changing an ID or path returns another user's file, authorization is missing (IDOR). Map users to authorized object IDs on the server; do not trust hidden fields or unguessability alone.

Question 40Web application and data-protection foundations

An XML parser is configured to resolve external entities. Which file-disclosure class is this, and what is the fix?

  1. CSRF via SOAP; add SameSite=Lax only
  2. XML external entity (XXE) processing; disable external entities and DTDs in the parser Correct answer.
  3. DOM XSS; set HttpOnly
  4. CORS misconfiguration; reflect Origin

Explanation

XXE lets a crafted XML document instruct the parser to fetch files or URLs while parsing. Production parsers should disable DTDs and external entities, and prefer formats that do not need DTD resolution.

Question 41Web application and data-protection foundations

A user changes a numeric id in a request and views another customer's record. What is this, and what is the fix?

  1. Insecure direct object reference; enforce server-side authorization on every object Correct answer.
  2. Clickjacking; set X-Content-Type-Options
  3. TLS stripping; enable FTP
  4. Safe behavior because IDs are not sequential UUIDs

Explanation

IDOR (a broken-access-control finding) is accessing another subject's object by manipulating an identifier. Unguessable IDs reduce discovery but do not replace an authorization check that the principal may access that object.

Question 42Web application and data-protection foundations

An unauthenticated visitor who knows the URL can load /admin. Hidden links were only omitted from the public menu. What is the failure?

  1. Missing SPF
  2. Excessive CSP
  3. Secure cookie flag on the admin page
  4. Missing server-side authentication and role authorization (security through obscurity) Correct answer.

Explanation

Forced browsing succeeds when authorization is not enforced on the resource. Hiding a URL is not a control. Require authentication and an admin role on the server for every admin handler.

Question 43Web application and data-protection foundations

Which statement correctly distinguishes horizontal from vertical access-control failure?

  1. Horizontal is TLS failure; vertical is HTTP/2 failure
  2. Horizontal is accessing another user at the same privilege level; vertical is reaching a higher privilege function Correct answer.
  3. Vertical is always XSS; horizontal is always CSRF
  4. They are synonyms for directory traversal

Explanation

Horizontal issues are peer-to-peer (user A reads user B's order). Vertical issues are privilege-boundary crossings (a standard user reaches admin functions). Both require server-side authorization; they are not named for transport versions.

Question 44Web application and data-protection foundations

A page hides the delete button in HTML and sets a disabled attribute based on a client-side role flag. The API still deletes if called directly. What is wrong?

  1. Nothing; UI hiding is sufficient access control
  2. Only the missing button is a usability bug
  3. Authorization must be enforced on the server; UI hiding is not a security control Correct answer.
  4. The API should trust the client-side role flag as the source of truth

Explanation

Presentation-layer hiding is not authorization. Every mutating API must re-check authentication and permissions. Client-supplied role flags are attacker-controlled.

Question 45Web application and data-protection foundations

Which principle should guide both application roles and database accounts used by a web app?

  1. Least privilege: grant only the rights needed for the function Correct answer.
  2. Shared superuser accounts for simpler operations
  3. All users mapped to the database sa or root login
  4. Disable logging so privileges cannot be audited

Explanation

Least privilege limits blast radius when injection or credential theft occurs. Application and database accounts should not share DBA, sa, or root rights.

Question 46Web application and data-protection foundations

What is the standard defense against session fixation?

  1. Reuse the pre-login session ID forever so the user is not inconvenienced
  2. Issue a new session identifier after authentication and invalidate the old one Correct answer.
  3. Put the session ID in every URL instead of a cookie
  4. Disable HTTPS so fixation cannot occur

Explanation

Session fixation imposes a known SID on the victim before login. Regenerating the identifier at authentication binds the authenticated session to a value the attacker does not have.

Question 47Web application and data-protection foundations

Which set of cookie attributes is the baseline for a session cookie on an HTTPS site?

  1. Secure, HttpOnly, and an explicit SameSite value (Lax or Strict unless a documented cross-site need exists) Correct answer.
  2. Secure omitted, HttpOnly omitted, SameSite=None without Secure
  3. Domain=.com with no path restriction
  4. HttpOnly omitted so JavaScript can cache the SID in localStorage as well

Explanation

Secure limits the cookie to HTTPS, HttpOnly blocks script access, and SameSite reduces CSRF. SameSite=None is only for true cross-site uses and must be paired with Secure.

Question 48Web application and data-protection foundations

Why is placing a session identifier in the URL a finding?

  1. URLs cannot be bookmarked
  2. HTTPS forbids query strings
  3. Search engines refuse to index URLs with parameters
  4. The identifier leaks via Referer, logs, history, and screenshots Correct answer.

Explanation

URL-borne session IDs (including rewritten paths such as jsessionid) appear in access logs, proxy logs, browser history, and the Referer header sent to third parties. Prefer cookie-based sessions with Secure and HttpOnly.

Question 49Web application and data-protection foundations

What is the difference between idle session timeout and absolute (maximum) session lifetime?

  1. They are the same control with two names
  2. Idle timeout is only for APIs; absolute timeout is only for HTML
  3. Idle timeout ends a session after inactivity; absolute lifetime ends it after a fixed period even if the user is active Correct answer.
  4. Absolute lifetime only applies when HttpOnly is missing

Explanation

Idle timeout limits unattended sessions. Absolute timeout bounds how long a stolen session can last even with continuous activity. Sensitive applications should implement both.

Question 50Web application and data-protection foundations

What must a logout function do to be effective?

  1. Only hide the logout link in CSS
  2. Invalidate the server-side session and instruct the browser to clear the session cookie Correct answer.
  3. Keep the server session valid so the user can click Back
  4. Print the session ID on the goodbye page for support

Explanation

Logout is a security control only if the server destroys the session record (or marks it invalid). Clearing the cookie without server invalidation leaves a stolen SID usable.