Cyber Security Quiz: Web App Auth Pitfalls

10 questions · exam conditions

0:00

Web App Auth PitfallsQuestion 1 of 10

A document portal displays an Edit button only when the signed-in user owns the document. Its API accepts PUT /api/documents/{documentId} requests. For each request, the server verifies a valid JWT and confirms that the token contains the documents:edit permission, but it does not compare the document's owner with the token's user identifier. A regular user changes the identifier in a captured request and successfully edits another user's document.

Which control would most directly correct the underlying authorization flaw?

Require the API to verify that the requester is authorized for the referenced document before processing the update.

Configure the client to hide document identifiers and disable editing controls for documents owned by other users.

Reduce the JWT lifetime so that a captured token can authorize document updates for a shorter period.

Require a CSRF token on update requests so that another website cannot submit an authenticated document change.

← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Web App Auth Pitfalls

Practice Web App Auth Pitfalls 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 Web App Auth Pitfalls, 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

Which control would most directly correct the underlying authorization flaw?

Require the API to verify that the requester is authorized for the referenced document before processing the update. (correct answer)
Configure the client to hide document identifiers and disable editing controls for documents owned by other users.
Reduce the JWT lifetime so that a captured token can authorize document updates for a shorter period.
Require a CSRF token on update requests so that another website cannot submit an authenticated document change.

Explanation: When you see a scenario where a user can manipulate a resource identifier to access something they shouldn't, you're looking at a Broken Object Level Authorization (BOLA/IDOR) flaw — one of the most common and critical API vulnerabilities. The key diagnostic question is: does the server verify not just that the user is authenticated, but that they are authorized for that specific resource? Here, the server correctly checks for a valid JWT and the documents:edit permission, but it never asks: "Does this token's user own this document?" That missing ownership check is the root cause. Answer A directly patches that gap — by requiring the server to compare the document's owner against the requester's identity before processing the update, you eliminate the flaw at its source. No amount of credential or token management fixes a missing authorization check. Answer B is a classic "security through obscurity" trap. Hiding UI controls or identifiers on the client side provides zero protection — an attacker can intercept and modify requests directly, bypassing the interface entirely. The API is what matters. Answer C addresses token lifetime, which is relevant to credential theft scenarios, but doesn't fix the authorization logic. Even a short-lived token still lets a user edit any document during its validity window. Answer D defends against Cross-Site Request Forgery — a legitimate control, but CSRF protects against unauthorized sites submitting requests on a user's behalf, not unauthorized users accessing resources they don't own. The study tip here: always distinguish authentication (who are you?) from authorization (are you allowed to do this to this specific resource?). BOLA flaws live entirely in that second question.

Question 2

A reverse proxy caches successful GET /account/summary responses using only the URL as the cache key. The origin personalizes the response based on the session cookie but does not send Cache-Control: private or no-store. Alice requests the page first. Bob later requests the same URL with his own valid session cookie and receives Alice's account summary.

Which change most directly prevents this cross-user authorization failure?

Add a restrictive Content Security Policy so cached account information cannot execute unapproved client-side scripts.
Rotate each user's session identifier after every summary request so cached identifiers become invalid more quickly.
Require a CSRF token on the summary request so another site cannot cause the browser to retrieve the page.
Prevent shared caching of personalized responses, or partition the cache using a trusted authenticated-user context. (correct answer)

Explanation: When you see a question about a caching vulnerability where one user receives another's personalized data, you're looking at a web cache poisoning / cache isolation problem. The root cause is always the same: the cache doesn't know the response is user-specific, so it serves one person's data to everyone requesting that URL. The fix that directly addresses this root cause is D. The origin server must signal to the cache that personalized responses must not be shared — typically via Cache-Control: private or no-store — or the cache must be configured to partition entries by authenticated identity (e.g., using a Vary: Cookie or Vary: Authorization header, or a per-user cache key). Either approach ensures Bob's request never resolves to Alice's cached response. This is the architectural fix that closes the vulnerability at its source. A is wrong because a Content Security Policy restricts what scripts can execute on a page — it does nothing to prevent one user's data from being served to another. It addresses XSS risk, not cache isolation. B is wrong because rotating session IDs more frequently doesn't fix the core problem. Bob still receives Alice's account summary data, even if the session identifier embedded in that response expires sooner. The sensitive content is already leaked. C is wrong because CSRF tokens protect against cross-origin requests forging actions on behalf of a logged-in user. The attack here isn't cross-site forgery — Bob is making a direct, legitimate request to the same URL and receiving the wrong response from the cache. Study tip: When a question describes one user seeing another's data, immediately ask where in the stack is data being conflated? If it's a cache, the fix lives in cache directives or cache-key design — not in authentication tokens or CSP.

Question 3

A password-reset service generates cryptographically random, short-lived tokens and stores only token hashes. To create the emailed reset link, it concatenates https://, the incoming HTTP Host header, and the reset path. The front end forwards requests containing arbitrary Host values. An attacker submits a reset request for a victim while supplying a domain controlled by the attacker as the header value.

Which remediation most directly prevents the resulting token-exposure path?

Generate reset URLs from a configured canonical origin and reject requests whose host is not on an explicit allowlist. (correct answer)
Shorten reset-token validity so a token disclosed when the victim follows the link expires more rapidly.
Encrypt reset tokens before including them in links so the attacker cannot determine the victim's account name.
Require HTTPS for reset links so intermediaries cannot observe the token while the victim opens the supplied host.

Explanation: When a service builds URLs dynamically using attacker-controlled input, you're looking at a Host header injection vulnerability. The key question to ask is: where does the token actually go? If the reset link points to the attacker's domain, the victim clicks it, and the token travels directly to the attacker's server — regardless of how strong, short-lived, or hashed the token is on the backend. A is correct because it eliminates the injection point entirely. By constructing reset URLs from a hardcoded, server-side canonical origin and validating incoming Host values against an explicit allowlist, the server never incorporates attacker-supplied input into the link. The token has nowhere malicious to go. B is a risk-reduction measure, not a fix. Shortening token lifetime shrinks the attack window, but if the attacker receives the token the moment the victim clicks the link, even a 60-second token is enough to compromise the account. This treats symptoms, not the cause. C is a red herring. The attack isn't about the attacker reading account names from the token — it's about receiving the raw token value when the victim's browser makes a request to the attacker-controlled host. Encryption doesn't prevent that HTTP request from happening. D misunderstands the threat model. HTTPS protects tokens from network eavesdroppers, but here the attacker is the destination server. TLS protects the channel, not the endpoint. Study tip: When a question describes attacker-controlled input flowing into a security-sensitive output (like a URL), the correct fix almost always involves input validation or elimination at the source, not compensating controls downstream.

Question 4

After password and MFA verification, an application offers a Remember this device option. It stores a cookie containing a Base64-encoded username, an expiration time, and trusted=true. On later logins, the server skips MFA whenever those fields appear valid. The cookie is marked Secure and HttpOnly, but it has no signature or server-side record.

Which redesign best addresses the authentication bypass?

Keep the encoded fields but set SameSite=Strict so another website cannot submit the trusted-device cookie cross-site.
Place the cookie in browser local storage so JavaScript can renew the trusted-device expiration after each login.
Use an unguessable server-tracked device token or an integrity-protected token with expiry and revocation support. (correct answer)
Retain the current cookie and require a longer password whenever the user initially enables the trusted-device option.

Explanation: When you see a question about "remember this device" or persistent authentication cookies, your core question should be: can an attacker forge or tamper with this token to bypass authentication? The flaw here isn't about transport security — it's about token integrity and accountability. The cookie contains user-controlled semantics (trusted=true) with no cryptographic signature and no server-side record, meaning anyone who crafts or steals the cookie can permanently skip MFA. Option C is the correct redesign because it attacks the root cause. Either an unguessable server-tracked token (a random opaque ID the server maps to a verified device record) or an integrity-protected token (such as an HMAC-signed or encrypted JWT) eliminates forgeability. Server-side tracking also enables revocation — critical if a device is lost or a session is compromised. Expiry enforcement adds a time boundary. This is defense in depth applied to persistent authentication. Option A adds SameSite=Strict, which prevents cross-site request forgery involving this cookie — a real but separate concern. It does nothing to stop an attacker who directly forges a cookie with trusted=true, since the server still accepts any structurally valid cookie. Option B is actively worse: moving the cookie to localStorage removes HttpOnly protection, exposing it to XSS attacks. It also doesn't fix the forgery problem at all. Option D is a distractor that mixes password strength with a completely unrelated vulnerability. A longer password doesn't prevent someone from crafting a fraudulent trusted-device cookie. Study tip: When a question involves cookies bypassing security controls, always ask whether the token is forgeable (no signature) and revocable (no server record). Those two gaps almost always point to the right fix.

Question 5

A banking site uses an authentication cookie configured as SameSite=Lax. The endpoint GET /profile/change-email?value=new@example.test changes the signed-in user's email address and requires no anti-CSRF token. In the target browsers, Lax cookies are included with top-level cross-site GET navigations. An attacker places a link to that endpoint on another site and persuades a signed-in user to follow it.

Which assessment is most accurate?

The request is blocked because SameSite=Lax excludes cookies from every navigation initiated by a different site.
The change can succeed because a top-level GET carries the cookie, and the endpoint improperly performs a state-changing action. (correct answer)
The change fails because browsers require a CORS preflight before allowing any cross-site navigation that includes cookies.
The change can succeed only if the attacker first reads the authentication cookie through cross-origin JavaScript.

Explanation: When you see a question involving SameSite cookies and cross-site requests, your instinct should be to trace exactly which request types each SameSite value restricts — because the devil is in the details. SameSite=Lax is a partial protection. It blocks cookies on cross-site subresource requests (like <img> or <iframe> loads) and cross-site POST form submissions. However, it deliberately allows cookies on top-level GET navigations — meaning if a user clicks a link that navigates their browser to another site, the cookie travels with it. The passage explicitly confirms this browser behavior. Since the /change-email endpoint accepts a GET request and performs a state change without requiring an anti-CSRF token, clicking that attacker-controlled link sends the authenticated cookie and successfully modifies the user's email. That's why B is correct — the vulnerability exists at the intersection of a permissive cookie policy and an endpoint that shouldn't use GET for mutations. A is wrong because it overstates Lax protections. Lax does not block every cross-site navigation — top-level GET navigations are explicitly permitted, which is the exact scenario described. C confuses CORS with CSRF. CORS preflights apply to cross-origin JavaScript-initiated requests (like fetch or XMLHttpRequest), not to simple browser navigations. Clicking a link is a navigation, not an XHR — no preflight occurs. D is wrong because the attacker never needs to read the cookie. The browser automatically attaches it to the navigation; the attacker only needs the user to click the link. Study tip: Memorize that SameSite=Lax still permits top-level GET cross-site navigations. Any state-changing GET endpoint is therefore still vulnerable to a link-based CSRF attack even with Lax configured.

Question 6

An administrative API accepts signed access JWTs with a one-hour expiration. Each token contains the user's role, and the API authorizes requests solely from that role claim. An administrator removes a user's administrative role in the identity database, but a previously issued token for that user still contains role: admin. The organization requires role removals to take effect immediately.

Which design best satisfies the stated requirement while retaining JWTs as access tokens?

Issue tokens over TLS and store them in HttpOnly cookies so users cannot inspect or alter their role claims.
Add the role-removal time to audit logs and rely on the existing token expiration to end administrative access.
Check a server-side revocation or token-version value during authorization and reject tokens issued before the role change. (correct answer)
Sign tokens with a stronger algorithm so a removed administrator cannot generate a replacement token containing the old role.

Explanation: When you see a question about JWT-based authorization, the core tension to recognize is that JWTs are stateless by design — once issued, the server has no built-in way to invalidate them before expiration. This becomes a critical security gap when permissions must be revoked immediately. The scenario describes exactly that gap: a token containing role: admin remains valid for up to an hour after the role is stripped from the database, because the API trusts the token's claims without consulting any server-side state. The only way to close this gap while keeping JWTs as access tokens is to introduce a lightweight server-side check at authorization time. Option C does precisely this — by storing a revocation list or a per-user token version number, the server can reject any token issued before the role change, making revocation instant regardless of expiration time. Option A is a red herring. Storing tokens in HttpOnly cookies prevents client-side JavaScript from reading them, which protects against XSS theft — but does nothing about a legitimate token carrying a stale role claim. The token is still accepted as-is. Option B describes accepting the security gap and waiting for natural expiration. This directly violates the stated requirement that removal takes effect immediately, making it the answer most students mistakenly choose when they confuse "eventually correct" with "correct." Option D addresses forgery, not staleness. A stronger signing algorithm prevents an attacker from crafting a new fraudulent token, but the user already has a legitimately signed token with the old role — no forgery needed. Your study tip: whenever a question mentions "immediate" revocation with stateless tokens, look for the answer that adds server-side state back into the authorization check.

Question 7

An administration endpoint permits requests only when middleware determines that the client IP is within an internal network. The application uses the leftmost value in X-Forwarded-For as the client IP without checking which system supplied the header. Although a reverse proxy normally fronts the application, the origin server is also reachable from the internet.

Which remediation best protects the endpoint against authorization bypass?

Log all forwarding-header values and generate alerts whenever a request claims an internal address alongside an unfamiliar browser user-agent string.
Require the reverse proxy to terminate TLS externally while allowing the origin to continue accepting arbitrary forwarding headers from any source directly.
Always use the rightmost X-Forwarded-For value because end clients cannot influence values that are appended further along the chain by downstream systems.
Accept forwarding headers only from trusted proxies, restrict direct internet access to the origin server, and derive the client address using a defined and verified proxy chain. (correct answer)

Explanation: When you see an IP-based authorization question, think about trust boundaries: who is allowed to supply identifying information, and can an attacker influence that data? Here, middleware blindly trusts the X-Forwarded-For header's leftmost value, which any client controls freely. An attacker reaching the origin server directly simply crafts a header like X-Forwarded-For: 192.168.1.1 and instantly appears to be an internal host — a classic IP spoofing bypass. The correct approach, D, closes every layer of this vulnerability simultaneously. By accepting forwarding headers only from verified, trusted proxies, you ensure that the IP chain hasn't been tampered with. Blocking direct internet access to the origin removes the attacker's ability to bypass the proxy entirely. Deriving the client address from a defined proxy chain means you reconstruct the true client IP by walking back through only the hops you trust — making forgery practically impossible. A is purely reactive: logging and alerting doesn't prevent the bypass; an attacker succeeds before any alert fires. Detection is not remediation. B is counterproductive. TLS termination at the proxy is good practice, but if the origin still accepts arbitrary forwarding headers from anyone on the internet, the spoofing vulnerability remains completely open. C contains a subtle misconception. The rightmost value is trustworthy only when every intermediary is trusted — if an attacker connects directly to the origin and supplies any X-Forwarded-For value, that value becomes the rightmost entry the origin sees. For exam strategy, remember: header-based trust requires verified sources. Whenever a question involves IP derivation from headers, ask yourself whether the application controls who can set those headers — not just which value it reads.

Question 8

An application creates a session identifier when a user first visits the site. The identifier remains unchanged after successful password and MFA verification. An attacker can cause a victim's browser to begin with a session identifier known to the attacker, but the attacker cannot read the victim's password or MFA response. After the victim signs in, the attacker submits the known identifier from another browser.

Which change most effectively prevents the described account compromise?

Mark the session cookie Secure so browsers transmit the known identifier only through encrypted HTTPS connections.
Regenerate the session identifier after authentication and invalidate the preauthentication identifier on the server. (correct answer)
Apply a shorter idle timeout to anonymous sessions while preserving their identifiers after successful authentication.
Add a CSRF token to the login form so the victim's credentials cannot be submitted from an external site.

Explanation: When you see a scenario where an attacker plants a known session token before authentication and then reuses it after the victim logs in, you're looking at a session fixation attack. The core vulnerability is that the session identifier survives the authentication boundary unchanged — meaning privilege escalates but the token stays the same. The fix is straightforward: the server must regenerate the session identifier immediately after successful authentication and invalidate the old one. This is exactly what B describes. Once the victim logs in, the server issues a fresh, unpredictable token. The attacker's pre-planted identifier becomes worthless because the server no longer recognizes it. The attacker gains nothing, even though they knew the pre-auth token. The distractors each address real security concerns — just not this attack. A (marking the cookie Secure) prevents the identifier from leaking over HTTP, but the attacker already knows the identifier — they set it. Encrypting its transmission doesn't help when theft isn't the problem. C shortens the anonymous session window, slightly reducing the attack's time window, but the identifier is still valid after login, so the attacker can still hijack the session before the timeout expires — it mitigates rather than eliminates. D (CSRF token on the login form) prevents cross-site credential submission, but the attacker isn't submitting the victim's credentials at all — they're submitting their own known identifier from a separate browser after the victim authenticates. A useful mental rule: authentication is a privilege boundary — any token crossing that boundary must be replaced. If a question describes a token surviving login, regeneration is almost always the answer.

Question 9

A web application uses an OAuth authorization-code flow for sign-in. The provider enforces an exact redirect URI, and authorization codes are short-lived and usable only once. However, the application neither sends nor validates a state value. An attacker begins a sign-in using the attacker's provider account, stops when the browser is redirected to the application's callback, and sends that callback URL to a victim.

What is the most likely security consequence if the victim opens the callback URL before the code expires?

The victim's browser may establish an application session associated with the attacker's provider account, enabling login CSRF or account confusion. (correct answer)
The attacker may learn the victim's provider password because the callback exposes credentials to the application in the URL.
The victim may obtain the attacker's provider access token directly because exact redirect matching does not protect token confidentiality.
The attacker may reuse the same authorization code after the victim because the absence of state disables one-time code enforcement.

Explanation: When you see a question involving OAuth flows and missing security parameters, your focus should be on what that missing parameter prevents — not just that it's absent. The state parameter in OAuth serves one critical purpose: it binds the authorization request to the user who initiated it. When a legitimate user clicks "sign in," the application generates a random state, stores it in the user's session, and includes it in the redirect. When the callback returns, the application verifies the state matches. Without this check, the application cannot confirm who triggered the authorization flow. This is exactly the Login CSRF vulnerability: an attacker initiates a sign-in using their own provider account, captures the resulting callback URL (which contains a valid code tied to the attacker's account), and tricks the victim into visiting it. The victim's browser submits the code, the application exchanges it for a token, and the victim's session becomes linked to the attacker's provider identity — enabling account confusion, data exposure, or account takeover. A is correct. B is wrong because the callback URL contains an authorization code, not a password. OAuth is specifically designed so credentials never travel through the application. C is wrong because exact redirect URI matching prevents code interception by third parties, but it does nothing to prevent the victim from voluntarily visiting a crafted callback URL — and no access token appears in the callback anyway. D is wrong because one-time code enforcement is handled server-side by the authorization server regardless of whether state is used; the absence of state doesn't disable that mechanism. When studying OAuth, remember: state prevents Login CSRF, PKCE prevents code interception, and exact redirect URIs prevent open-redirect hijacking — each parameter defends against a different threat.

Question 10

An API authenticates users with cookies configured as SameSite=None; Secure. For every request, the API copies the request's Origin value into Access-Control-Allow-Origin and also returns Access-Control-Allow-Credentials: true. A malicious site runs JavaScript that sends a credentialed request to an endpoint returning the signed-in user's profile.

What is the most likely outcome in a browser that follows these response headers?

The request may be sent, but the response remains unreadable because credentialed CORS forbids a wildcard allowed origin, so only an explicitly listed origin grants script access.
The malicious script may read the profile because its specific origin is reflected back and credentials are explicitly permitted by the response headers. (correct answer)
The request is treated as unauthenticated because cross-origin browser requests never include cookies, regardless of cookie or CORS settings.
The script may alter the profile but cannot read it because CORS controls response access only for read operations, not for state-changing requests.

Explanation: Whenever you see a question mixing CORS and cookies, mentally trace two separate questions: will the browser send credentials? and will the browser expose the response to the script? Cookies flagged SameSite=None; Secure are explicitly designed to accompany cross-origin requests — that's the whole point of that configuration. So when the malicious site makes a credentialed fetch(), the browser does attach the victim's cookies. On the server side, reflecting the request's own Origin header back into Access-Control-Allow-Origin paired with Access-Control-Allow-Credentials: true satisfies every CORS requirement: the origin is explicit (not a wildcard), and credentials are permitted. The browser therefore hands the response body to the malicious script, which can read the victim's profile. That's exactly what answer B describes. A is close but wrong about the mechanism. It correctly notes that a wildcard origin blocks credentialed reads — but the server isn't returning a wildcard. It's echoing the malicious site's exact origin, which is a perfectly valid explicit origin. This is precisely what makes the vulnerability so dangerous. C is a flat misconception. Cross-origin requests absolutely can include cookies when both the cookie's SameSite attribute and the CORS headers allow it, as they do here. D confuses CORS with CSRF protections. CORS governs whether a script can read cross-origin responses — it doesn't separately block writes. And the scenario is about reading the profile, not mutating state. As a study tip: remember that origin-reflection is a classic CORS misconfiguration. Any server that echoes Origin → Access-Control-Allow-Origin with credentials enabled is functionally equivalent to allowing every site on the internet to read authenticated responses.