Trace a browser request, distinguish method guarantees, and test session and access-control claims against HTTP evidence.
45 min 120 XPSkills: HTTP mechanics, Session security, Access-control evidence
Brief
At Halcyon Clinics, a patient clicks a billing link twice after a slow page load. Two charges appear. The support lead calls it a browser cache problem; the developer says the application is stateless, so duplicate transactions are impossible. Meanwhile, an access-review export counts every HTTP response as a successful read, including denied requests.
You will follow the exchange from a URL through a server response and a later session-bearing request. Your goal is to distinguish transport success from business success, repeatability from read-only behavior, and proof of identity from permission. These distinctions let you ask for evidence that tests the actual control rather than a reassuring label.
A page rendering, a connection succeeding, and an action being authorized are three different observations.
Clients, servers, and the address being requested
A client initiates a request; a server receives it and chooses a response. These are roles, not device sizes: an application server can also be a client of another service. In https://portal.example.test:8443/bills/42?view=summary#total, https is the scheme, portal.example.test is the host, 8443 is an explicit port, /bills/42 is the path, view=summary is the query, and total is the fragment. HTTPS normally uses port 443 when no port is supplied. The fragment is handled by the client and is not sent as part of the HTTP request target.
The client resolves the host to a network address and establishes protected communication for HTTPS before exchanging application data. An HTTP/1.1 example is GET /bills/42?view=summary HTTP/1.1 with a Host header carrying portal.example.test:8443. A response has a status code, headers, and possibly a body; newer HTTP versions encode the same semantics differently. TLS protects data in transit, not whether the caller is allowed to read bill 42. For access-control evidence, retain a redacted route, method, outcome, and correlation identifier; an auditor should ask whether tests exercise the server directly instead of merely hiding a button. Avoid recording sensitive query values or full billing bodies.
The client sends the path and query, while the fragment stays local.
Methods: safe is not the same as idempotent
A safe method requests no state change as its intended effect. GET and HEAD are safe; incidental logging does not change that classification. HEAD retrieves response metadata without response content. Idempotent means repeating an identical request has the same intended server effect as sending it once. GET, HEAD, PUT, and DELETE are idempotent by their defined semantics, but PUT and DELETE are not safe. Deleting an already deleted bill may return 404 after an initial 204; differing responses do not disprove idempotency. A GET that charges a card violates safe semantics even if its URL looks like a read.
POST commonly creates or processes something and has no general idempotency guarantee. PATCH also has no blanket guarantee, though a specific patch operation can be designed to be idempotent. If a payment POST times out after the server commits, an automatic retry can create a second charge. A documented deduplication key with a defined scope and retention window can make that operation retry-safe; the method name alone cannot. Change-control evidence should include repeated-request tests and persisted transaction identifiers. Ask whether the duplicate test simulates a lost response after commit, rather than only a request that never arrived.
Status codes and headers are evidence, not a verdict on the whole system
Status classes describe an individual exchange: 1xx is informational, 2xx successful, 3xx redirection, 4xx a client-side request problem, and 5xx a server-side failure. A 201 reports creation, 204 success with no response content, 302 a redirect, 404 a missing resource, and 503 temporary unavailability. A 200 response may still contain an application-level error if the service was designed that way; collectors must inspect its documented response schema. Conversely, a 403 from a forbidden access test is evidence of a functioning denial, not proof the service is broken.
A 401 means the request lacks valid authentication credentials and normally includes a WWW-Authenticate challenge. A 403 means the server refuses the request; a common case is a validly authenticated user without permission, although 403 does not universally prove a user was authenticated. Some services deliberately use 404 to conceal resource existence. Request headers such as Authorization convey credentials; Content-Type describes a representation, Accept expresses preferences, Location identifies a redirect or created resource, and Cache-Control directs cache behavior. For confidentiality controls, test private responses for appropriate cache directives such as no-store and verify server-side denials. An auditor needs documented code semantics and redacted test traces, not a count of all completed responses as successful access.
Stateless HTTP can carry a stateful session
HTTP does not inherently remember a prior exchange. After login, a server can issue Set-Cookie: sid=<opaque-token>; Secure; HttpOnly; SameSite=Lax; Path=/. On a later eligible request the browser sends Cookie: sid=<opaque-token>; the server maps that unpredictable token to a session record with an identity, expiry, and other state. Cookie attributes are instructions from the response, not repeated as attributes in the Cookie request header. Session state can live server-side despite HTTP statelessness; alternatively, a service can validate a signed client-held token, which changes revocation and storage tradeoffs rather than eliminating security obligations.
Secure restricts cookie transmission to secure connections; HttpOnly blocks access through script cookie APIs, but malicious script may still cause authenticated requests. SameSite controls cookie attachment in cross-site contexts: Strict is most restrictive, Lax permits certain top-level navigations using safe methods, and None permits cross-site use and requires Secure in modern browsers. Same-site and same-origin are not identical boundaries. Cookie flags do not replace authorization or complete CSRF defenses: combine suitable SameSite policy with anti-CSRF tokens or origin checks for state-changing operations. Rotate session identifiers after login or privilege change, expire idle and absolute lifetimes, and invalidate the session on logout. For session-management controls, collect redacted cookie attributes and tests proving an old token fails after logout; never collect live tokens as audit evidence.
A cookie links independent HTTP exchanges to revocable server-side session state.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The disappearing anchor
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
A tester opens https://portal.example.test/bills/42?view=summary#total. The server log includes view=summary but never total. A manager insists the missing value proves a proxy stripped authorization data, and orders a network incident. The tester confirms the page simply scrolls to a labelled section.
1.2Which URL component contains total and stays client-side? (one word)
Task 2: A retry is not a read
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
A deletion endpoint correctly implements DELETE. The first call removes a record and returns 204; the second returns 404 without further changes. An engineer calls it non-repeatable because the status changed, then calls it read-only because repeating it causes no additional deletion.
Term bank, not all of these are right
idempotentunsafesafenon-idempotent
2.1Which method property is demonstrated by the unchanged intended effect after repetition? (one word)
2.2Under the safe-versus-unsafe classification, which describes this deletion? (one word)
Task 3: Denied is not unauthenticated
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
A billing service documents 401 for missing or expired credentials and 403 for an authenticated user lacking the billing role. A valid session without that role is refused. Separately, a script reads a session token through the cookie API; the cookie already has Secure and SameSite=Lax. The lead says encryption should have prevented both events.
Term bank, not all of these are right
401403HttpOnlySecure
3.1Under this service's documented mapping, which code belongs to the role-based refusal? (a number)
3.2Which missing cookie attribute would block direct script access through the cookie API? (one word)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon Clinics is publishing a machine-readable contract for its billing reader. The draft owner proposes a write method because 'all encrypted calls are safe' and wants to retain live session cookies in the evidence bundle.
Complete the YAML from the fixture. Use booleans for flags, integers for codes, and the SameSite mode named by policy. Supply a short evidence description that refers to redacted traces or sanitized traces instead of collecting credentials.
Approved billing-reader requirements
Operation: read bill 42 without requesting any business-state change; use GET.
URL: https://portal.example.test/bills/42?view=summary#total
Contract path excludes query and fragment.
No valid session: 401. Valid session, no billing role: 403.
Session cookie: HTTPS only, unavailable to script cookie APIs.
Policy selects SameSite=Lax to allow ordinary cross-site top-level safe navigations.
Logout must invalidate the server session, not just remove the browser cookie.
Evidence: redacted traces or sanitized traces; never live credentials.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Checks
Read method and resource path match the contract
Safe and idempotent classifications are distinct and correct
Credential and role failures use the documented codes
Cookie attributes meet transport, script, and navigation requirements
Logout revokes server-side session state
Evidence describes sanitized exchanges, not credentials
A release reviewer claims any encrypted exchange is authorized and any stateless protocol cannot support sessions. Review six assurance notes before they reach the audit packet.
Accept technically correct claims and reject incorrect ones using the narrowest listed reason. Reason codes mean: method-semantics = incorrect method guarantees; auth-boundary = identity confused with permission; cookie-boundary = cookie protection overstated; state-model = protocol and application state confused.
Verdicts are accept or reject. Every rejection needs one reason code from: method-semantics | auth-boundary | cookie-boundary | state-model.
Release assurance notes
AHW-1: DELETE is idempotent even if the first response is 204 and a later response is 404.
AHW-2: GET may charge a card as its intended action because safe means encrypted.
AHW-3: This service returns 401 for expired credentials, so 401 proves the user's billing role was checked and refused.
AHW-4: HttpOnly stops direct script cookie API reads but does not stop all authenticated requests initiated by malicious script.
AHW-5: Secure alone prevents CSRF because encrypted cookies cannot accompany attacker-triggered requests.
AHW-6: Stateless HTTP makes a server-side session store impossible.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Application Fundamentals
APIs and Data Formats
Read API contracts, preserve complete evidence collections, and distinguish signed credentials from secret data.
