Cyber Security Quiz: Csrf And Mitigations
10 questions · exam conditions
0:00
Csrf And MitigationsQuestion 1 of 10

A website protects all actions performed after authentication with session-bound CSRF tokens. Its login endpoint, however, accepts a cross-site POST containing only a username and password. An attacker submits the attacker's own valid credentials through the victim's browser. The victim later enters personal information without noticing which account is active.

Which control most directly prevents this login-CSRF scenario while preserving password-based login?

Issue a pre-authentication CSRF token and require it to match the browser's pre-login session at login.
Rotate the authenticated session identifier after login but accept the cross-site credential submission.
Require complex passwords so an attacker cannot determine the credentials submitted by the victim's browser.
Escape the username before displaying it so supplied credentials cannot introduce executable page content.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Csrf And Mitigations

Practice Csrf And Mitigations in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Csrf And Mitigations, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A website protects all actions performed after authentication with session-bound CSRF tokens. Its login endpoint, however, accepts a cross-site POST containing only a username and password. An attacker submits the attacker's own valid credentials through the victim's browser. The victim later enters personal information without noticing which account is active.

Which control most directly prevents this login-CSRF scenario while preserving password-based login?

  1. Issue a pre-authentication CSRF token and require it to match the browser's pre-login session at login. (correct answer)
  2. Rotate the authenticated session identifier after login but accept the cross-site credential submission.
  3. Require complex passwords so an attacker cannot determine the credentials submitted by the victim's browser.
  4. Escape the username before displaying it so supplied credentials cannot introduce executable page content.
Explanation: When you see a question about CSRF, your first instinct should be to identify which request lacks forgery protection — not just whether CSRF tokens exist somewhere on the site. Here, the vulnerability is specifically at the login endpoint, where an attacker can force the victim's browser to submit the attacker's own credentials, logging the victim into the attacker's account (a "login CSRF" attack). Option A is the correct control because it closes this exact gap. By issuing a pre-authentication CSRF token tied to the victim's anonymous session, the server can verify that the login POST originated from the legitimate browser that received that token — not from a cross-site form the attacker controlled. This requires no changes to the password-based flow; users simply submit a hidden token along with their credentials. Option B describes session fixation mitigation (rotating the session ID post-login), which is a good practice but does nothing to prevent the cross-site credential submission itself — the attacker's account is still logged in before any rotation occurs. Option C is a red herring. Password complexity is irrelevant here; the attacker is submitting their own known credentials, not guessing the victim's. The strength of any password involved doesn't affect whether the forged request succeeds. Option D addresses XSS prevention through output encoding. While always good practice, escaping a displayed username does nothing to prevent a cross-site POST from being accepted in the first place. The key study takeaway: CSRF protection must cover every state-changing endpoint, including login. Tokens protecting post-auth pages leave the login door wide open to account-hijacking through login CSRF.

Question 2

A cookie-authenticated service accepts cross-site cookies using SameSite=None; Secure. Its state-changing endpoint accepts application/x-www-form-urlencoded POST requests and has no CSRF token. The server's CORS policy does not allow the attacker's origin, so an attacker cannot read the endpoint's response using JavaScript.

Which conclusion is correct?

  1. The endpoint is protected because denying CORS prevents the browser from transmitting any cross-origin POST request.
  2. The endpoint is protected because form-encoded requests always trigger a preflight that the server will reject.
  3. The endpoint may be vulnerable because a cross-site form can send the POST with cookies without reading the response. (correct answer)
  4. The endpoint may be vulnerable only if the attacker first obtains the value of the victim's session cookie.
Explanation: Whenever you see a question mixing CSRF, CORS, and SameSite cookies, your first instinct should be to separate two distinct questions: Can the browser send the request? and Can the attacker read the response? CORS only governs the second question — it never blocks the browser from sending a request. Here's the core reasoning for why C is correct: CSRF attacks don't need to read the server's response. The attacker's goal is to trigger a state change — transferring funds, changing an email address, deleting data. A plain HTML <form> with method="POST" and enctype="application/x-www-form-urlencoded" is a same-site-free request that the browser sends natively, attaching any cookies scoped to the target origin. Because the cookie is configured with SameSite=None; Secure, the browser will include it on cross-site requests by design. No JavaScript is involved, so CORS is completely irrelevant. With no CSRF token on the endpoint, there is no mechanism to distinguish the legitimate request from the forged one. A is wrong because CORS restrictions are enforced by the browser after the request is sent — they prevent JavaScript from reading the response, not from sending the request. The POST still goes through. B is wrong because application/x-www-form-urlencoded is explicitly a CORS simple content type, meaning no preflight (OPTIONS) request is triggered. Preflights only apply to non-simple requests. D is wrong because the attacker never needs the cookie value. The browser attaches it automatically on behalf of the victim — that's the entire premise of CSRF. Study tip: Memorize that CORS ≠ CSRF protection. If an endpoint accepts simple form POST requests and relies solely on cookies with SameSite=None, the absence of a CSRF token is a real vulnerability regardless of CORS configuration.

Question 3

A reverse proxy caches the HTML for /settings without varying the cache by user or session. The page contains a hidden CSRF token. The application server validates that token against the authenticated user's server-side session. After caching is enabled, many users receive a form containing the token originally generated for another user's session.

What is the most likely security result, and what is the appropriate correction?

  1. Browsers remove the cached token automatically; place the same token in the URL to preserve it during submission.
  2. All submissions succeed securely; a token remains trustworthy as long as it was generated with strong randomness.
  3. Users inherit the cached user's session; rotate every session cookie whenever a settings page is requested.
  4. Most submissions fail validation; prevent shared caching of tokenized pages or generate tokens for the correct session. (correct answer)
Explanation: When you see a question combining caching, authentication, and CSRF tokens, think about the binding between a security token and a specific user's session. CSRF tokens only work as a defense when each user's form contains a token tied to their session — if that binding breaks, the protection collapses. Here's what's happening in the scenario: the reverse proxy caches the HTML page, token included, and serves that same static snapshot to every subsequent visitor. When User B submits the form, the server compares the cached token (originally bound to User A's session) against User B's session — they won't match. The result is widespread validation failures for legitimate users, and the CSRF protection is simultaneously rendered useless. The correct fix is to either mark the response as private/uncacheable (Cache-Control: no-store or Vary by session) or generate tokens dynamically per session before serving the page. D captures both the problem (failed validation) and the solution (stop caching tokenized pages or generate correct tokens). A is dangerously wrong on two levels: tokens in URLs leak through referrer headers and server logs, and browsers have no mechanism to automatically strip or replace cached tokens. B ignores the binding requirement entirely — token strength is irrelevant if the token belongs to a different user's session; the server will still reject it. C confuses the attack model. Receiving someone else's token in a cached HTML page doesn't transfer their session cookie — those are separate browser-stored credentials not touched by the cache. Your study tip: CSRF tokens must be session-specific. Any mechanism — caching, prefetching, or template errors — that decouples a token from the user receiving it invalidates the entire CSRF defense.

Question 4

An API accepts cookie-authenticated state-changing requests from the application's own browser interface. Instead of using per-request tokens, it verifies the Origin header. If Origin is absent, it checks Referer. The deployment team proposes accepting requests with both headers absent because some privacy tools remove referrer information.

Which policy provides the strongest CSRF protection without confusing origin validation with CORS?

  1. Reject requests whose available origin does not match, and treat both headers being absent as a controlled exception or failure. (correct answer)
  2. Accept requests whenever Origin is absent because browsers omit it only for requests initiated by trusted pages.
  3. Return Access-Control-Allow-Origin: * so browsers can supply trustworthy origin information on every request.
  4. Compare only the URL path in Referer, because matching paths demonstrate that both pages share an origin.
Explanation: When tackling CSRF protection questions, focus on what the defense actually accomplishes: ensuring that state-changing requests originate from a trusted source, not a malicious third-party site. The Origin and Referer headers provide source-of-request signals, but neither is guaranteed to be present — and your policy must handle that gap deliberately. The strongest approach, reflected in A, is to treat a missing origin signal as a failure state rather than an implicit pass. When both Origin and Referer are absent, you cannot confirm the request came from your own application, so the safest response is to reject or escalate it as a controlled exception. This closes the door that attackers could exploit by stripping headers. Some legitimate privacy tools do strip these headers, but the correct architectural response is an out-of-band exception mechanism (e.g., an allowlist for specific clients), not blanket acceptance. B is dangerously wrong. Browsers do not reliably omit Origin only for trusted pages — cross-origin requests from attacker-controlled pages can also lack Origin in certain contexts. Trusting absence as a trust signal inverts the logic of security. C confuses two entirely separate mechanisms. Access-Control-Allow-Origin: * is a CORS header that controls what cross-origin JavaScript can read from responses — it does nothing to authenticate or validate incoming requests and actually widens access rather than restricting it. D is flawed because the Referer URL path says nothing meaningful about shared origin. Two completely different sites can share a URL path structure; origin is defined by scheme, host, and port — not path. As a study tip: whenever a question blends CORS and CSRF concepts, ask yourself which mechanism controls reading responses (CORS) versus validating request sources (CSRF) — they operate in opposite directions and should never be conflated.

Question 5

A payment application must operate inside iframes embedded by unrelated merchant sites. Its authentication cookie must therefore be available in a legitimate cross-site context. The application also performs sensitive state changes from within the embedded interface.

Which design best preserves the required functionality while providing meaningful CSRF protection?

  1. Use SameSite=Strict for the authentication cookie and require merchants to retry blocked iframe requests.
  2. Use SameSite=Lax and perform sensitive changes through top-level GET navigations from the iframe.
  3. Use SameSite=None without Secure and rely on iframe embedding to establish the merchant's trust.
  4. Use SameSite=None; Secure and validate unpredictable session-bound tokens on state-changing requests. (correct answer)
Explanation: When a web application must function inside cross-site iframes and perform sensitive state changes, you're balancing two competing requirements: cookie accessibility across origins and protection against forged requests. The key insight is that these goals aren't mutually exclusive — they require layered defenses. Because the payment app lives inside iframes on unrelated merchant sites, the authentication cookie must travel in cross-site requests. That immediately rules out SameSite=Strict (option A), which blocks cookies entirely in cross-site contexts — merchants can't "retry" their way around this; the iframe simply won't authenticate. Option B fails for a different reason: SameSite=Lax still blocks cookies in cross-site subresource requests like iframes, and routing sensitive state changes through GET navigations is doubly wrong — GET requests should never cause state changes, and top-level navigations break the embedded UX entirely. Option C recognizes that SameSite=None is necessary for cross-site iframes, but omitting Secure is a critical flaw: browsers reject SameSite=None cookies without Secure, and transmitting session cookies over HTTP exposes them to interception. Trusting iframe embedding as a security boundary is not a real defense mechanism. Option D is correct because SameSite=None; Secure satisfies the cross-site cookie requirement while the session-bound CSRF token provides the actual forgery protection. Even if an attacker triggers a cross-site request, they cannot read or reproduce an unpredictable token tied to the victim's session. As a study tip, remember that SameSite alone is not sufficient CSRF protection in cross-site contexts — pair it with token validation whenever SameSite=None is required.

Question 6

A single-page application stores an access token only in JavaScript memory and sends it in an Authorization: Bearer ... header. The API does not use cookies, HTTP authentication, or client certificates. An attacker can cause the victim's browser to submit ordinary cross-site requests but cannot execute code in the application's origin or learn the token.

What is the most accurate assessment of conventional CSRF risk in this design?

  1. CSRF remains unchanged because browsers automatically attach JavaScript-held bearer tokens to all requests for the API.
  2. CSRF is reduced because the browser does not automatically attach the required bearer token to the forged request. (correct answer)
  3. CSRF is eliminated only if the API also places the bearer token in a SameSite=Strict authentication cookie.
  4. CSRF becomes more likely because the same-origin policy requires cross-site forms to include authorization headers.
Explanation: When evaluating CSRF risk, the core question is always: what does the browser attach automatically? CSRF attacks work by exploiting the browser's habit of automatically including credentials — cookies, HTTP auth headers — on every request to a domain, even requests initiated from a malicious third-party site. If a credential must be explicitly attached by JavaScript code, a cross-site forged request simply won't carry it. In this design, the access token lives only in JavaScript memory and travels via an Authorization: Bearer header. That header is set programmatically by the application's own JavaScript — the browser has no mechanism to attach it automatically to requests originating from another site. So when an attacker tricks the victim's browser into submitting a forged cross-site request, that request arrives at the API without a token, and the API rejects it. This is why B is correct: conventional CSRF risk is meaningfully reduced because the forged request cannot carry the required credential. A is wrong because it describes how cookies behave, not bearer tokens. Browsers do not automatically attach JavaScript-held tokens — that's precisely what makes this pattern safer against CSRF. C is a contradictory trap: placing the token in a SameSite=Strict cookie would actually reintroduce cookie-based auth and bring CSRF risk back into the picture, requiring SameSite protections to mitigate it. D is simply false — the Same-Origin Policy restricts reading cross-origin responses but does not cause browsers to inject authorization headers into cross-site requests. As a study pattern, remember: cookies = automatic attachment = CSRF risk; explicit JS-set headers = no automatic attachment = CSRF largely mitigated.

Question 7

An application correctly validates unpredictable, session-bound CSRF tokens on every state-changing request. A stored cross-site scripting vulnerability is then discovered in a page served from the same application origin. The injected script runs while an authenticated user views that page.

How does the XSS vulnerability affect the application's CSRF protection?

  1. It has no effect because same-origin scripts are still prohibited from reading CSRF tokens embedded by the server.
  2. It can undermine the protection because injected same-origin script can obtain tokens or issue valid authenticated requests. (correct answer)
  3. It matters only when tokens are placed in cookies lacking Secure, because HTTPS otherwise isolates page scripts.
  4. It converts the vulnerability into clickjacking, so frame-ancestor restrictions become the primary token defense.
Explanation: When you see a question pairing CSRF protection with XSS, you should immediately think about what CSRF tokens actually protect against and what XSS actually enables. CSRF defenses assume the attacker cannot read or forge requests from the victim's origin — but XSS destroys that assumption entirely. CSRF tokens work because a malicious third-party site cannot access content from a different origin (the Same-Origin Policy blocks cross-origin reads). However, a stored XSS payload runs within the legitimate origin. That injected script has the same privileges as any other script on the page — it can read the DOM, extract a CSRF token embedded in a form or meta tag, and then use fetch() or XMLHttpRequest to submit a fully authenticated, token-bearing request on the victim's behalf. The CSRF protection never had a chance to matter, because the attacker is operating from inside the trusted origin. So B is correct. A is wrong because it assumes Same-Origin Policy protects CSRF tokens from same-origin scripts — it doesn't. SOP restricts cross-origin access; a script already running on the origin faces no such restriction. C is a distractor mixing up two separate concerns. The Secure cookie flag prevents transmission over HTTP, but it has no bearing on whether a same-origin script can read a token from the page's HTML or issue requests in the current session. D is simply fabricated. XSS does not "convert" into clickjacking; they are distinct attack classes with different mechanics and defenses. A useful mental model: think of CSRF tokens as a lock on the front door — XSS hands the attacker a key from inside the house, making the lock irrelevant.

Question 8

A banking application authenticates users with a session cookie configured as SameSite=Lax. Its legacy transfer endpoint changes account data through GET /transfer?to=...&amount=.... An attacker cannot embed the request successfully as a cross-site image, but can persuade a logged-in user to click a link that opens the transfer URL as a top-level navigation.

Which assessment best describes the remaining CSRF risk?

  1. The transfer is protected because SameSite=Lax suppresses cookies for every request initiated by another site.
  2. The transfer may succeed because Lax cookies can accompany a cross-site top-level GET navigation. (correct answer)
  3. The transfer may succeed only if the bank has configured CORS to allow the attacker's origin.
  4. The transfer is protected because browsers prohibit cross-site links from targeting authenticated endpoints.
Explanation: When tackling CSRF questions, your first move should be to map out exactly what the SameSite attribute does and doesn't block — because the three modes (Strict, Lax, None) each leave different attack surfaces open. SameSite=Lax was designed as a middle-ground: it blocks cookies on cross-site subresource requests (images, iframes, fetch calls) but deliberately allows cookies on cross-site top-level GET navigations — meaning when a user clicks a link that causes the browser to navigate to a new URL as the main page. This exception exists so that normal link-following across the web still works. The attack described in the passage exploits exactly this gap: the attacker crafts a link to GET /transfer?to=...&amount=... and tricks the user into clicking it. Because the browser treats that click as a top-level navigation, it sends the session cookie along with the request. The transfer executes. Answer B is correct. Answer A is wrong because it overstates what Lax provides. Lax does not suppress cookies for every cross-site request — that's the behavior of SameSite=Strict. The distinction between Strict and Lax is precisely what this question tests. Answer C is a category error. CORS governs which origins can read cross-origin responses in JavaScript — it has no bearing on whether the browser sends cookies with a request. CSRF is about forging requests, not reading responses. Answer D is simply false. Browsers place no such prohibition on cross-site links; following a link is a fundamental browser behavior. Your study tip: memorize the Lax exception — top-level GET navigations carry the cookie. Any application that changes state via a GET parameter is vulnerable even under Lax.

Question 9

A web application includes its CSRF token in action URLs, such as https://portal.example/change-email?csrf=TOKEN. The token is valid for the current session. Users can follow links from the resulting page to external websites, and the application uses the browser's default referrer behavior.

Why is this implementation weaker than placing the token in the body of a state-changing form?

  1. A URL token can appear in browser history, logs, and potentially referrer information, increasing the chance of disclosure. (correct answer)
  2. A URL token is automatically treated as a bearer authorization credential by every standards-compliant browser.
  3. A URL token cannot be compared with server-side session state because query parameters are processed before cookies.
  4. A URL token causes the browser to omit the session cookie whenever the request uses encrypted HTTPS transport.
Explanation: When evaluating CSRF token placement, think about attack surface and information leakage — specifically, how many unintended parties might observe the token in transit or at rest. Embedding the CSRF token in a URL query parameter exposes it through multiple channels that form body parameters never touch. Browser history records full URLs including query strings, so any shared or compromised device leaks the token passively. Server access logs routinely capture complete request URLs, meaning the token persists in log files accessible to system administrators, log aggregation services, or attackers who breach those systems. Most critically, when a user follows an external link from the resulting page, the browser's Referer header sends the full originating URL — including your CSRF token — to the destination server. Since the passage explicitly states users follow external links with default referrer behavior, this is the scenario being described. A token in a POST body is never included in the Referer header and never appears in browser history. Answer A correctly identifies all three disclosure vectors. Answer B is fabricated — browsers have no such standard treating URL query parameters as bearer credentials. Answer C is technically false; cookies and query parameters are both fully available during server-side request processing with no ordering constraint that would prevent token comparison. Answer D inverts reality — HTTPS protects cookies in transit rather than suppressing them; the connection between encryption and cookie omission doesn't exist. As a study tip: whenever a question contrasts URL parameters against form body fields, immediately think leakage paths — history, logs, and Referer headers are your three-point checklist.

Question 10

An application uses host-only session cookies on app.example.com. For CSRF protection, it places a random value in a second cookie scoped to Domain=example.com and accepts a request when that value equals a form parameter. The value is not signed or otherwise tied to the authenticated session. An attacker gains control of promo.example.com but cannot read responses from app.example.com.

Which change most directly addresses the important weakness in this design?

  1. Permit state changes only through POST, while retaining the domain-scoped cookie and equality comparison.
  2. Mark the CSRF cookie HttpOnly, while continuing to copy its value into each form parameter.
  3. Bind or sign the submitted token using the authenticated session and verify that binding on receipt. (correct answer)
  4. Enable permissive credentialed CORS for all HTTPS origins under the example.com domain.
Explanation: When evaluating CSRF defenses, always ask: what prevents an attacker from forging the protected value? If the answer is "nothing except obscurity," the defense is broken. Here, the CSRF token is a random value stored in a Domain=example.com cookie — meaning any subdomain, including the attacker-controlled promo.example.com, can write a new cookie into that shared domain space. The attacker doesn't need to read the existing token; they simply plant a known value in the CSRF cookie, then craft a form that submits that same value as the parameter. The equality check passes, and the request succeeds. This is the classic cookie-jar overflow / subdomain cookie injection attack against the Double Submit Cookie pattern. C is correct because binding or signing the token to the authenticated session breaks this attack. If the server verifies that the submitted token is cryptographically tied to the specific session (e.g., HMAC'd with a session secret), an attacker-planted cookie value will never produce a valid signature, even if they control its raw content. A fails because restricting to POST doesn't prevent the subdomain from injecting a cookie and submitting a POST form — the core vulnerability is unaffected by HTTP method restriction. B is a trap: HttpOnly prevents JavaScript from reading the cookie, but the attacker's goal is to write a cookie, not read one. This does nothing to stop cookie injection from promo.example.com. D makes things worse — opening credentialed CORS to sibling subdomains would give attackers more cross-origin capability, not less. For exam questions involving subdomain trust, always ask whether an attacker can write rather than just read shared cookies — that distinction separates weak patterns from strong ones.