Cyber Security Quiz: Client Server Trust Boundaries
10 questions · exam conditions
0:00
Client Server Trust BoundariesQuestion 1 of 10

An invoicing portal displays only the authenticated user's invoices. When a user selects an invoice, the browser requests /api/invoices/4821. The API verifies that the requester is authenticated and that invoice 4821 exists, but it does not compare the invoice owner with the requester.

Which assessment most accurately identifies the trust-boundary failure?

The client should encrypt invoice identifiers so users cannot derive identifiers belonging to other accounts.
The server must authorize access to the requested invoice even though the client displays only permitted invoice links.
The server should accept the identifier because authentication already establishes which invoices the client may display.
The client should validate that the identifier is numeric before issuing the request to the invoice API.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Client Server Trust Boundaries

Practice Client Server Trust Boundaries 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 Client Server Trust Boundaries, 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

An invoicing portal displays only the authenticated user's invoices. When a user selects an invoice, the browser requests /api/invoices/4821. The API verifies that the requester is authenticated and that invoice 4821 exists, but it does not compare the invoice owner with the requester.

Which assessment most accurately identifies the trust-boundary failure?

  1. The client should encrypt invoice identifiers so users cannot derive identifiers belonging to other accounts.
  2. The server must authorize access to the requested invoice even though the client displays only permitted invoice links. (correct answer)
  3. The server should accept the identifier because authentication already establishes which invoices the client may display.
  4. The client should validate that the identifier is numeric before issuing the request to the invoice API.
Explanation: When a question describes a server that checks authentication but skips ownership verification, you're being tested on Broken Object Level Authorization (BOLA) — one of the most common API vulnerabilities. The core principle: authentication answers who you are, but authorization answers what you're allowed to access. These are separate checks, and both must happen server-side. The scenario exposes a classic trust-boundary failure: the server confirms the user is logged in and that invoice 4821 exists, but never asks "does this user own invoice 4821?" An attacker can simply swap the ID in the URL to /api/invoices/4822 and retrieve someone else's invoice. This is exactly what B identifies — the server must enforce authorization on the specific resource being requested, regardless of what the client happens to display. A is a red herring. Encrypting or obfuscating identifiers is "security through obscurity" — it makes IDs harder to guess but doesn't actually enforce access control. A determined attacker can still discover valid IDs through other means. C represents the dangerous misconception the scenario is designed to expose: authentication does not imply authorization. Knowing who the user is tells you nothing about whether they should access a specific record. D is a client-side input validation concern (preventing malformed requests), which is completely unrelated to the ownership authorization failure at the heart of the problem. As a study tip: whenever you see a scenario where a server verifies identity but not ownership of a specific resource, the answer will always point to server-side object-level authorization. Client-side controls are never sufficient substitutes.

Question 2

An internal API contains sensitive employee records and allows cross-origin browser requests only from https://hr.example. The development team proposes removing API authentication because browsers from other origins will be blocked by the configured cross-origin resource sharing policy.

What is the most important flaw in the team's reasoning?

  1. The allowed origin must be concealed because otherwise an attacker can copy it into the HTTP Origin header.
  2. Cross-origin resource sharing authenticates the browser user but does not determine the employee records that user owns.
  3. Cross-origin resource sharing is primarily browser-enforced and does not stop direct clients from sending requests to the API. (correct answer)
  4. The policy protects direct API access, but it cannot prevent an allowed page from displaying records in the browser.
Explanation: Whenever you see a question about access controls or API security, ask yourself: who or what is actually enforcing this restriction, and can it be bypassed? That framing is exactly what this question tests. CORS is a browser-side security feature. When a browser receives an HTTP response containing CORS headers, it decides whether to expose that response to the requesting JavaScript based on whether the origin matches. The critical insight is that the API server has no way to distinguish a legitimate browser from any other HTTP client. Tools like curl, Postman, or a custom script simply never send an Origin header — or can send whatever value they choose — and the server happily responds. Removing authentication because "CORS will block unauthorized access" ignores this entirely. Answer C identifies this fatal flaw: CORS enforcement lives in the browser, so any non-browser client bypasses it completely, leaving the API fully exposed. Answer A is wrong because the allowed origin (https://hr.example) doesn't need to be secret — CORS doesn't work as a secret handshake. Even knowing the origin value doesn't help an attacker, because the browser itself enforces the block on their end. Answer B is a distractor that confuses CORS with authorization (which records a user can see) — CORS doesn't authenticate users at all, but that's not the flaw being exploited here. Answer D has the causality backwards; CORS restricts what a cross-origin page can read, but it doesn't prevent an allowed page from doing anything — and more importantly, it still doesn't address non-browser clients. As a study rule: CORS ≠ authentication or server-side access control. Anytime a question suggests CORS can replace API authentication, the answer will point out that server-side controls are the only reliable enforcement layer.

Question 3

An online store sends product prices and discount rules to the browser. The browser calculates the order total and submits item identifiers, quantities, a coupon code, and the calculated total. The checkout API verifies that the total is formatted as currency but otherwise charges the submitted amount.

Which allocation of responsibility most directly corrects the trust-boundary problem?

  1. The client should round each item price consistently and submit a checksum of the displayed order total.
  2. The client should disable editing after calculating the total and submit the order immediately to reduce tampering.
  3. The server should compare the submitted total with the value displayed in the browser before processing payment.
  4. The server should derive the charge from authoritative prices, quantities, coupon rules, and customer eligibility data. (correct answer)
Explanation: When you see a question about client-submitted data affecting financial calculations, think about the trust boundary principle: never trust input from a party who has an incentive to manipulate it. The server is the only environment you control; the client (browser) is controlled by the user. The core problem here is that the server charges whatever total the client submits, only checking its format. A malicious user can intercept the request and change the total to $0.01 before it's sent — the server will happily charge it. The fix isn't to better validate the client's math; it's to eliminate the client's math from the equation entirely. Option D does exactly this: the server independently recalculates the charge using its own authoritative data — prices from its database, quantity limits, verified coupon logic, and customer eligibility rules. The submitted total becomes irrelevant to what's actually charged, closing the trust boundary violation at its source. Option A fails because a checksum only detects tampering during transmission; an attacker can simply recalculate the checksum after modifying the total — you've added a lock and handed the attacker a key. Option B is security theater: disabling the UI doesn't prevent someone from using developer tools or a proxy to modify the HTTP request before it reaches the server. Option C is the subtlest trap — comparing the submitted total against "the value displayed in the browser" still trusts client-side data. The displayed value can also be manipulated; you're comparing two untrusted numbers. The study tip: whenever business-critical values (prices, totals, permissions) flow from client to server, the correct answer will always move authoritative calculation to the server — not add more client-side validation.

Question 4

A password-reset page disables its submission button for one minute after each request and stores the last-request time in browser storage. The reset API itself accepts any number of correctly formed requests. The team argues that the interface prevents abuse because ordinary users cannot click the button repeatedly.

Which control best addresses the trust-boundary weakness without relying on the page's behavior?

  1. Store the cooldown in a hidden form field so each request carries evidence that the browser waited long enough.
  2. Enforce rate and abuse limits at the server using relevant account, source, and risk signals. (correct answer)
  3. Increase the browser cooldown and obfuscate the JavaScript function that re-enables the submission button.
  4. Reject requests without browser storage enabled so every supported client retains its previous submission time.
Explanation: Whenever you see a security question involving client-side controls, immediately ask yourself: who actually enforces this rule, and can an attacker bypass that enforcer? The core principle here is that trust boundaries separate components you control from those you don't. Anything running in the user's browser — timers, JavaScript, local storage — is fully under the attacker's control, not yours. The scenario describes a classic mistake: the API imposes no restrictions, trusting the browser to behave honestly. An attacker using curl, Burp Suite, or any scripting tool never touches the browser's UI, so the one-minute cooldown is completely invisible to them. B is correct because server-side rate limiting based on account identity, IP, and risk signals operates at a layer the attacker cannot manipulate. The control lives where the attacker must go: the API endpoint. A is a trap that deepens the same vulnerability. Moving the cooldown timestamp into a hidden form field still keeps enforcement logic on the client — an attacker simply forges the field to claim they waited. C compounds the original mistake by adding obscurity (obfuscation) to a fundamentally flawed client-side control; obfuscation slows a curious observer but stops no determined attacker. D misunderstands the problem entirely — requiring browser storage rejects legitimate users with privacy settings but does nothing to stop an attacker who can fake or manipulate storage values just as easily. A useful mental shortcut: never trust input or behavior that originates on the client side. On security exams, any answer that hardens a client-side control without adding real server-side enforcement is almost always a distractor.

Question 5

A document portal permits only PDF uploads. Its web page restricts the file chooser to .pdf files and checks the browser-reported MIME type before upload. The server stores each file under a generated name and later serves it to other users, but performs no content validation.

Which change best places upload validation at the appropriate trust boundary?

  1. Have the server inspect the received content, enforce size and format policy, and serve it using a controlled content type. (correct answer)
  2. Have the client verify both the file extension and MIME type, then include those results as signed request headers.
  3. Have the server accept browser-approved files because generated storage names prevent uploaded content from changing format.
  4. Have the client rename every selected file with a .pdf extension before transmitting it to the document server.
Explanation: Whenever you see a question about input validation, anchor yourself to the concept of trust boundaries: validation only protects a system when it happens at the point where untrusted data enters a trusted environment. Client-side checks are cosmetic — an attacker can bypass a browser file picker, spoof a MIME type, or craft a raw HTTP request entirely, so any validation performed only on the client side is worthless as a security control. Answer A is correct because it moves all meaningful validation to the server — the actual trust boundary. By inspecting file content (not just the name or reported type), enforcing size and format policy, and controlling the Content-Type header when serving files, the server ensures that no matter what the client sends, only safe, validated content reaches other users. This is defense at the right layer. Answer B is a trap that sounds technical but misunderstands trust. Signed headers prove the client performed a check, but they don't prove the check was meaningful or that the file is actually safe. An attacker controls the client, so a signed "I checked it" header is no more trustworthy than the file itself. Answer C is dangerously wrong. It confuses storage obfuscation with content validation. A generated filename prevents directory traversal guessing but does nothing to stop a malicious file from being stored and later served — attackers don't need to predict filenames if the server retrieves and delivers the file for them. Answer D simply adds a .pdf extension client-side, which changes nothing about the file's actual contents and is trivially bypassed. Study tip: On security exams, any answer that relies solely on client-side controls to enforce a security policy is almost always wrong — the server must validate independently.

Question 6

An auction closes at a specified instant. To make the interface responsive, the browser records the time when the user clicks Place bid and includes that timestamp in the request. The server accepts a bid as timely whenever the submitted timestamp is before the deadline, even if the request arrives afterward.

Which redesign most appropriately handles the client-server trust boundary?

  1. Accept the client timestamp if it is formatted correctly and falls within the browser's displayed countdown interval.
  2. Synchronize browser clocks with the server periodically and then treat submitted browser timestamps as authoritative.
  3. Use an authoritative server-side timing rule for acceptance while treating the client timestamp as informational metadata. (correct answer)
  4. Reject only timestamps that differ substantially from receipt time, because small differences prove the client clock is honest.
Explanation: Whenever you see a question involving data submitted by a client (timestamps, prices, scores, etc.), ask yourself: who controls this value, and can they manipulate it? This is the core of the client-server trust boundary — a foundational principle that any input originating from the client must be treated as untrusted until the server independently validates it. In this scenario, the server is delegating a security-critical decision — whether a bid is timely — to a value the client supplies. That's the vulnerability. A malicious user could simply forge a timestamp before the deadline and submit a bid seconds, minutes, or hours late. Option C fixes this correctly: the server records its own authoritative timestamp the moment the request arrives, uses that for acceptance logic, and only keeps the client timestamp as non-binding metadata (useful for logging or UX analytics). The client loses all power to manipulate bid timing. Option A is wrong because formatting validation says nothing about authenticity — a well-formatted timestamp can still be a lie. Option B is wrong because clock synchronization reduces drift but doesn't prevent a user from deliberately submitting a false timestamp; "synchronized" does not mean "tamper-proof." Option D is the subtlest trap: rejecting only large discrepancies still lets attackers submit timestamps slightly before the deadline — small, plausible offsets — which is precisely the exploit they'd use. Study tip: On security exams, any answer that grants the client authority over a security decision is almost always wrong. Train yourself to spot phrases like "accept the client timestamp" or "treat submitted values as authoritative" as red flags.

Question 7

A browser application stores a signed access token. The browser decodes the token, hides privileged controls when the token has expired, and deletes it when the user's session ends. The API verifies the token's signature and reads its role claim, but does not validate the expiration, issuer, or audience claims.

Which change best addresses the misplaced trust in this design?

  1. Have the API validate the signature and applicable claims, then perform authorization for each requested operation. (correct answer)
  2. Have the browser encrypt the signed token before storing it, then send the decryption key with each request.
  3. Have the API trust expiration decisions made by the browser because the token signature protects the role claim.
  4. Have the browser check the issuer and audience claims before displaying links to privileged API operations.
Explanation: When evaluating API security designs, ask yourself: where is trust being enforced, and by whom? The golden rule is that security decisions must be made by the server, never delegated to the client. Browsers are untrusted environments — users can manipulate local storage, intercept traffic, and forge client-side logic. The scenario describes a classic case of misplaced trust: the API only verifies the token's signature but ignores expiration, issuer, and audience claims. This means an attacker could replay an expired token, or present a valid token from a different service, and the API would still authorize the request. The browser hiding UI controls is purely cosmetic — it provides zero security enforcement. A is correct because it moves all validation — signature and claims — to the API, and couples that with per-operation authorization checks. This ensures the server, not the client, makes every access decision. No claim goes unverified, and no operation is permitted without explicit server-side authorization. B is a red herring. Encrypting the token and sending the decryption key alongside it is pointless — you've added complexity while giving an attacker everything they need in a single request. Encryption without key secrecy provides no protection. C describes the exact vulnerability in the passage. Trusting the browser to enforce expiration while relying on the signature alone doesn't help — expiration must be validated server-side regardless of signature validity. D keeps enforcement in the browser. Even if the browser checks issuer and audience, a determined attacker bypasses the browser entirely and calls the API directly. Remember: the client controls what it sends, but the server controls what it allows. Any check the client skips, an attacker can skip too.

Question 8

A banking application uses TLS for every connection. Before submitting a transfer, its mobile client checks that the destination account is in the user's saved-payee list and that the amount is below the user's transfer limit. The server accepts the destination and amount after confirming only that the request arrived over TLS.

Which statement best describes the remaining security issue?

  1. TLS guarantees request confidentiality but not integrity, so an intermediary can freely alter the destination account in transit.
  2. TLS protects the transport channel, but the server must still validate authorization and transfer limits for client-supplied values. (correct answer)
  3. TLS makes the official mobile application trustworthy, but the server must reject requests from ordinary web browsers.
  4. TLS validates the transfer rules only when mutual TLS is used, so client certificates would replace server-side checks.
Explanation: When you see a question involving TLS and application security, the key concept to recognize is the boundary between transport security and application-layer security. TLS secures the channel — it encrypts data in transit and authenticates the server — but it says absolutely nothing about whether the content of a request is authorized or valid. These are two completely separate responsibilities. This is exactly what makes B correct. The scenario describes a classic case of misplaced trust: the server assumes that because a request arrived over TLS, it must be legitimate. But any attacker can send a crafted HTTPS request directly to the server, bypassing the mobile app entirely. The client-side checks (payee list validation, transfer limits) are purely cosmetic from a security standpoint — they only protect honest users from themselves. The server must independently verify authorization and enforce business rules on every request, regardless of how it arrived. A is wrong because TLS actually does provide integrity — it uses MAC-based authentication to detect tampering in transit. An intermediary cannot silently alter data inside a valid TLS session. C is a red herring. TLS does not make any particular client application trustworthy, and blocking web browsers is not a meaningful security control — attackers can spoof headers or use any HTTP client. D is incorrect. Mutual TLS authenticates the client device, not the user's authorization for a specific action. Even with mTLS, server-side business logic enforcement remains required. For the exam, remember this rule: TLS ≠ authorization. Whenever a scenario shows a server trusting client-supplied values just because they arrived securely, the answer will always point to missing server-side validation.

Question 9

A web application uses a three-step onboarding wizard. The browser enables the final submission button only after identity information, policy consent, and payment details have been entered. However, the final API endpoint accepts a complete-looking JSON payload without checking whether the earlier steps were completed or whether consent was recorded.

Which design most effectively prevents a modified client from bypassing the onboarding workflow?

  1. Store the current wizard step in a hidden form field and require the final request to contain the value 3.
  2. Minify the wizard code and generate unpredictable names for the client functions that enable each step.
  3. Require the browser to submit all three screens together so the final payload contains every displayed field.
  4. Maintain authoritative workflow state on the server and permit finalization only after server-validated prerequisites are satisfied. (correct answer)
Explanation: Whenever you see a question about client-side controls versus server-side enforcement, anchor yourself to a core security principle: never trust the client. An attacker can intercept, modify, or replay any request the browser sends, regardless of what the UI enforces. With that lens, D is clearly correct. Storing workflow state authoritatively on the server — and requiring each step to be validated before the next is permitted — means a malicious actor cannot simply craft a JSON payload and skip steps. Even if an attacker bypasses the entire browser UI, the server independently confirms that identity, consent, and payment prerequisites were completed and recorded. The client's role becomes irrelevant to security. The distractors each represent a common but flawed pattern. A stores the wizard step in a hidden form field, which an attacker can trivially modify before sending the request — setting it to 3 requires zero skill and defeats the entire control. B relies on obfuscation: minifying code or randomizing function names slows down a casual observer but provides no real barrier. Any determined attacker can inspect network traffic directly and replay or modify API calls without ever touching the JavaScript. C sounds stricter because it bundles all three screens into one payload, but the server still has no way to verify that consent was genuinely presented and acknowledged — the attacker just includes all the expected fields in one crafted request. The study takeaway: on security exams, any control that lives exclusively in the client (hidden fields, JavaScript logic, UI state) is never a sufficient security boundary. Real protection requires server-side validation of every security-relevant decision.

Question 10

A single-page registration application checks password length, confirms that the two password fields match, and prevents submission until the user accepts the terms of service. A tester discovers that the registration API accepts requests that bypass all three browser checks.

Which change best preserves the intended client-server trust boundary while retaining a responsive user experience?

  1. Obfuscate the client-side validation code so users cannot easily determine which checks the application performs.
  2. Perform all checks only in the browser and reject requests whose user-agent does not match the supported application.
  3. Keep the browser checks for immediate feedback, but independently enforce the required conditions in the registration API. (correct answer)
  4. Remove the browser checks and perform validation only after the server has created the new user account.
Explanation: When you see a question about input validation in web applications, the core concept being tested is the client-server trust boundary: client-side code runs in an environment the user controls, so any check performed only in the browser can be bypassed by crafting direct API requests — exactly what the tester demonstrated here. The real question is where authoritative validation must live. Option C is correct because it respects this boundary without sacrificing usability. Browser-side checks give users instant feedback (no round-trip delay), while the server independently re-validates every condition — password length, field matching, and ToS acceptance — before processing the request. Neither layer trusts the other; they serve complementary roles. Option A is a classic security-through-obscurity trap. Obfuscating JavaScript doesn't prevent bypass; a tester simply inspects network traffic and sends raw API requests, never touching the browser code at all. Obscurity is not a control. Option B compounds the problem with a user-agent check, which is trivially spoofed in any HTTP client. Relying on browser-only validation while filtering by user-agent still leaves the API unprotected against anyone who sets the right header string. Option D removes the feedback layer entirely, degrading the user experience with no security benefit. Worse, performing validation after account creation means a malformed or malicious record could already exist in the database before it's rejected — creating potential inconsistencies or race conditions. Study tip: On security exams, whenever a question contrasts client-side and server-side controls, remember: client = convenience, server = enforcement. Any security control that only exists client-side is not a security control at all.