The consent gate accepts a code request only when Sec-Fetch-Site is same-origin or none. For every other request the fallback to the /squeek-connect/ consent page is itself keyed on a Fetch Metadata header (Sec-Fetch-Mode: navigate).

A browser that implements no Fetch Metadata at all (Safari and iOS WebKit before 16.4, Firefox before 90, and some embedded WebViews) sends neither header, so a signed-in player who follows the game's login link gets a raw 403 {"error":"CONSENT_REQUIRED"} body rendered as the page. Even a player who reaches /squeek-connect/ by hand cannot proceed: the Continue link is a GET that again carries no Sec-Fetch-Site, so consented is false and the same 403 is returned.

Section 2 of AUDIT_REQUEST.md states that browsers without fetch metadata 'always go through the consent page'; the code gives them neither the page nor a way to finish. No security impact (fail closed), but the 鼠道修仙 sign-in is unavailable to that whole browser class and the failure mode is an unexplained JSON document instead of a message.

Fix (preserving the consent requirement): (1) when Sec-Fetch-Mode is absent, treat a GET whose Accept includes text/html as a navigation and redirect to /squeek-connect/ as for other navigations; (2) give the consent page a proof that does not depend on Fetch Metadata, e.g. make Continue a same-origin to a small /api/squeek/consent route that checks Origin === issuer (browsers without Fetch Metadata do send Origin on POST) and the session cookie, then 303s to authorize with a short-lived single-use consent nonce bound to the session hash, which authorize accepts as equivalent to Sec-Fetch-Site: same-origin.

Add a test with a signed-in cookie and no sec-fetch-* headers asserting a 303 to /squeek-connect/ and a completed login.

The remediation for finding 4 states that 'the token UPDATE now consumes the code on every attempt within its 60 s'. The UPDATE that marks consumed_at and writes 'rejected' only runs after the request body passes shape validation.

An exchange that presents the correct, live code together with a wrong redirect_uri, a wrong client_id, a grant_type other than authorization_code, or a code_verifier that is not exactly 43 base64url characters is answered 400 BAD_REQUEST before the database is touched, so the code remains unconsumed and is still accepted by a later, well-formed exchange.

RFC 6749 section 4.1.3 treats a redirect_uri or client mismatch as a failed use of the code; the stated single-attempt guarantee does not hold on these paths.

Impact is limited: PKCE still binds the grant to the verifier, so a stolen code cannot be exchanged without it, and the code lives 60 s. The defect is that the guarantee the fix claims (any failed attempt spends the code, so a thief's probe burns it and the legitimate exchange fails loudly) is not provided on these paths.

Fix: once code is a syntactically valid 43-char token, run the consuming UPDATE even when the other body fields are wrong, i.e. validate grant_type/client_id/redirect_uri/code_verifier inside the CASE (bind redirect_uri and the computed challenge, or 'invalid' when the verifier is malformed) and return 400/401 after the UPDATE.

Add a test: mint a code, POST token with redirect_uri 'https://squeekascension.celestao.com/x' and the right verifier (expect 400), then POST the correct exchange and assert 401 INVALID_GRANT and consumed_at set.

Finding 4 of 64b1ce06 made a code conditional on Sec-Fetch-Site being same-origin or none (line 115). The fallback for every other case (line 116-118) only redirects to /squeek-connect/ when the request also carries Sec-Fetch-Mode: navigate; otherwise it answers 403 {error:'CONSENT_REQUIRED'} as JSON. A browser that sends no Fetch Metadata at all (Safari before 16.4, every WebKit on iOS 16.3 and older, any WebView built on them) sends neither Sec-Fetch-Site nor Sec-Fetch-Mode.

For such a browser: (a) the game's top-level navigation to /api/squeek/authorize with a valid World cookie gets a 403 JSON body rendered as text, never the consent page; (b) even if the player opens /squeek-connect/ by hand and presses Continue, that same-origin click also arrives without Sec-Fetch-Site, so consented is false and the answer is again 403 JSON. There is no path on which such a client can obtain a code, so the login is impossible rather than consent-gated.

Section 2 of AUDIT_REQUEST.md states the opposite ('Browsers that send no fetch metadata always go through the consent page'). The test '64b1ce06 #4' only covers the case site=null together with sec-fetch-mode: navigate, so the fully header-less navigation is untested. Before this commit the same signed-in client received a code, so this is a regression for those clients.

Fix: when both Sec-Fetch-Site and Sec-Fetch-Mode are absent, treat a GET whose Accept includes text/html as a navigation and send it to /squeek-connect/ (as the request already does for navigate), and on the consent page use a POST form (same-origin, with the session cookie and a CSRF token or the existing Origin check) for Continue so that consent is proven by the request itself instead of by a header those browsers do not send.

If the owner prefers to keep header-only consent, state in section 2 that clients without Fetch Metadata cannot sign in, and have the game show that message instead of the raw JSON.

Fetch Metadata defines Sec-Fetch-Site: none as any user-originated navigation, which includes a link clicked in an external application (chat client, mail client, PDF viewer, OS link handler) and opened in the default browser, not only a typed or bookmarked URL. Section 2 discloses only the typed/bookmarked case.

So a third party who sends a signed-in player a prepared /api/squeek/authorize link (with the third party's own code_challenge and state) obtains a code for the victim's wallet without the victim ever seeing /squeek-connect/; the browser is redirected straight to the game's redirect_uri carrying world_code and world_state.

The impact is bounded: the code is delivered only to the victim's own browser at the fixed game origin and is PKCE-bound to the third party's verifier, so the third party cannot exchange it unless the game forwards the code to a place the third party can read. It is also observable by the victim (the game opens).

It is reported because the remediation text claims 'no site can mint a code silently' and the consent click is presented as the guarantee; the guarantee does not hold for links delivered outside a web page. Fix (if the owner wants the click to be the guarantee): accept only Sec-Fetch-Site: same-origin for code issuance and send 'none' through /squeek-connect/ like every other value; the only cost is that a typed or bookmarked authorize URL also gets the one-click page.

The render order on lines 55-57 tests order first and owned second. When checkout/state returns a pending order (existing row for this request key) and owned=true (the same wallet paid another order for the same sku, e.g. two tabs or two game purchase keys, the case AUDIT_REQUEST section 2 of Submission28 discloses as 'the first payment to land wins'), the page shows the original order and the 'Sign payment of 200 GOLD' button instead of the ALREADY_OWNED notice.

Pressing it runs operate(true): client.state (owned=true is ignored), goldChallenge succeeds only if the server pre-check passes; createEconomyGoldChallenge already refuses with ALREADY_OWNED (economy-ledger.ts line 268), and the debit batch would refuse through SQUEEK_ONE_TIME_SQL anyway, so no GOLD is taken. The gap is a flow one: the page asks the player to confirm a payment the server will always refuse, and the page's own data (owned) already says so.

Fix: in the pending-order branch, when data.owned is true render the ALREADY_OWNED status (and the order id for reference) and no button; in operate(true) throw ALREADY_OWNED before requesting a challenge when latest.owned is true.

Finding 4 made a code conditional on Sec-Fetch-Site being same-origin or none (line 115). For every other request the handler redirects to /squeek-connect/ only when Sec-Fetch-Mode is 'navigate'; otherwise it answers 403 CONSENT_REQUIRED (or 401 AUTH_REQUIRED) as JSON.

A browser that sends no fetch metadata at all (Safari and iOS Safari before 16.4, and any WebView built on them) therefore sends neither header: a top-level navigation from the game lands on a raw JSON 403 instead of the consent page. Even if such a user opens /squeek-connect/ by hand and presses Continue, that same-origin GET again carries no Sec-Fetch-Site, so it is again 403.

Section 2 of AUDIT_REQUEST.md states that 'browsers that send no fetch metadata always go through the consent page'; the code does not do that, and for those browsers the login cannot be completed at all. Before this commit a signed-in user on such a browser was issued a code; now the route is dead for them.

No security impact: this is a correctness/availability defect of the fix.

Fix: (a) when Sec-Fetch-Mode is absent, treat a GET whose Accept contains text/html as a navigation for the redirect; and (b) do not make the consent click itself depend on Sec-Fetch-Site. Let /squeek-connect/ submit a same-origin POST (form or fetch with credentials) to the authorize endpoint and accept it when the Origin header equals the issuer, which every browser sends on POST; keep the Sec-Fetch-Site GET path only as an additional acceptance for modern browsers.

The fix for the next finding is the same change.

The consent gate treats Sec-Fetch-Site: none as 'the user's own navigation (a typed or bookmarked URL)'. Browsers send 'none' for every navigation that has no web initiator: not only the address bar and bookmarks, but any URL handed to the browser by another application (a link clicked in a native mail client, Slack/Discord/Telegram desktop or mobile apps, a PDF viewer, a QR scanner, an OS intent).

An attacker who gets a signed-in player to tap such a link therefore skips /squeek-connect/ entirely: the authorize endpoint mints a code bound to the attacker's code_challenge and state and redirects the victim to the game with it.

The attacker still cannot read the code (the redirect is fixed and PKCE binds the verifier), so the concrete effect is the one the request wants ruled out: a code is created for a signed-in victim without their click on World, and the victim's game tab receives an authorization response with a state it did not create. The game's handling of a foreign state is outside this package. The 'none' allowance is only needed because consent is expressed as a GET navigation.

Fix: express consent as a same-origin POST from /squeek-connect/ (Origin header must equal the issuer; add a one-time CSRF value stored with the session if desired) and stop treating Sec-Fetch-Site: none on a GET as consent; a typed URL then simply lands on the consent page like any other. This preserves the owner's design (one click on World) and also fixes the previous finding.

Order in authorize(): query validation, then the per-client limiter 'squeek:authorize:'+ip (AUTH_LIMITER, 20 a minute per IP in production via worker/app.ts allow('home',key)), then readSession (one D1 read), and only then the Sec-Fetch-Site consent check. A request that will be refused for lack of consent therefore still spends the victim's budget and costs a database read.

Any cross-site page the signed-in player visits can embed 20 hidden iframes or images pointing at a well-formed authorize URL; each is refused (303 to the consent page or 403) but each spends one unit of the victim's IP budget. For the next 60 seconds the player's own Continue click on /squeek-connect/ answers 429 RATE_LIMITED, and the attacker page can repeat this every minute while open. Players behind one NAT share the key, so one such page affects all of them.

Impact is limited to the squeek login (other sign-in budgets use different keys).

Fix: evaluate the consent condition (headers only) before the limiter and before readSession; for an unconsented request answer the 303/403 immediately with no budget spent and no database read, then spend the budget and read the session only for consented requests. The existing tests keep passing (64b1ce06 #4 asserts only the status and that no code row exists).

Finding 4 made every exchange attempt consume the code and rejects the second use with 401. RFC 6749 section 4.1.2 adds that when a code is used more than once the server SHOULD revoke all tokens previously issued on it, because a second use means the code leaked (the game's URL with world_code sits in the victim's history and can be forwarded to a third party, and the window is the 60 s TTL).

As written, if an attacker exchanges a leaked code first, the legitimate game gets 401, starts a new login, and the attacker keeps a valid read-only grant for up to an hour (balance, entitlements, order keys of that wallet). If the legitimate game exchanges first, an attacker's later attempt yields nothing, so the gap is only the first ordering; the grant is read-only and dies with the World session, which bounds the impact to Low.

The code row already stores token_hash for the consumed code, so the information needed to revoke is present.

Fix: in token(), when the UPDATE returns 0 rows, run one statement UPDATE squeek_tokens SET revoked_at=?now WHERE token_hash=(SELECT token_hash FROM squeek_auth_codes WHERE code_hash=?hash AND token_hash<>'rejected') AND revoked_at IS NULL, still answering 401; add a test that after exchange, exchange, the first grant's snapshot answers 401.

Finding 4 of 64b1ce06 is fixed on the assumption that Sec-Fetch-Site: none means 'a typed or bookmarked URL' (AUDIT_REQUEST.md section 2). Browsers send none for every navigation whose initiator is not a web origin: the address bar and bookmarks, but also a link opened from a desktop or mobile chat client, a mail client, a PDF, an OS deep link, or a native/Electron wrapper that hands a URL to the system browser.

The World session cookie is __Host-imd_session with SameSite=Lax (source/server/auth.ts:603), so such a top-level GET carries it. The route therefore mints a code and 303s to the fixed game redirect with no consent page.

A third party gains little (the code only reaches https://squeekascension.celestao.com/ and is bound to the attacker's own code_challenge), but the party the consent page is meant to protect the player from, the game operator, can skip it entirely by opening the authorize URL from a native build of the game or from any message the player clicks outside a browser, which contradicts the stated design ('every login from the game now stops on /squeek-connect/ for one click').

The designed flow never needs none: the Continue link on /squeek-connect/ is a same-origin navigation.

Fix: consented=site==='same-origin'; a typed or bookmarked URL then goes through the consent page once, which the owner already accepts for every game login. Optionally also require sec-fetch-mode: navigate for code issuance.

Finding 2 moved the budgets in front of the database, but in authorize the budget is spent before the consent/fetch-metadata decision at lines 115-118. The budget key is the client IP (rateLimitKey(cf-connecting-ip), worker/app.ts:201) under AUTH_LIMITER, 20 per minute per IP (wrangler.jsonc:52).

A GET subresource (<img src> or fetch(...,{mode:'no-cors'})) from any site sends no Origin header, so the authorize-route origin check at line 199 passes; the parameters are static and public (client_id, fixed redirect, any 43-char challenge, any state), so validation passes; the budget is then spent even though the request carries no cookie (SameSite=Lax) and is answered 401.

Twenty such requests per minute from the victim's browser leave the victim's own navigation, and every other player behind that NAT, with 429 RATE_LIMITED. The sibling checkout route does it the other way round: it refuses a non same-origin Sec-Fetch-Site at line 160 before touching its budget.

Fix: in authorize, before deps.allow, answer 403 CONSENT_REQUIRED (or 401) when sec-fetch-mode is present and not navigate, or when sec-fetch-site is cross-site/same-site and the request is not a navigation; and consider keying the budget by session hash for signed-in requests so a cookieless flood cannot touch a signed-in player's allowance.

AUDIT_REQUEST.md section 1 row 4 says 'The token UPDATE now consumes the code on every attempt within its 60 s'. Only attempts that pass body validation reach the UPDATE at lines 135-145. An attempt carrying the real code with a different redirect_uri, client_id or grant_type, or a verifier that is not 43 base64url characters, is refused at this line and the code stays usable until its expiry.

RFC 6749 section 4.1.2 only requires revocation on reuse, so this is not a security defect: a holder of the code without the verifier still cannot obtain a grant, and the wrong-verifier case (the one that matters) is spent as claimed. It is recorded so the game's specification and the disclosure ('a code that reaches the token endpoint with a wrong verifier is spent') are read as the exact behaviour: wrong verifier spends, malformed request does not.

No change is needed; if the broader statement is wanted, run the UPDATE whenever b.code matches OPAQUE regardless of the other fields.

Finding 4 of 64b1ce06 made code issuance conditional on Sec-Fetch-Site being same-origin or none (line 115). For every other request, including one with no Sec-Fetch-Site at all, the fallback to the /squeek-connect/ consent page is itself keyed on another Fetch Metadata header: line 117 redirects only when Sec-Fetch-Mode is 'navigate'; otherwise line 118 answers 403 {error:'CONSENT_REQUIRED'} as JSON.

A browser that implements no Fetch Metadata (Safari and iOS WebKit before 16.4, Firefox before 90, WebViews built on them) sends neither header, so (a) the game's top-level link to /api/squeek/authorize lands on a raw JSON 403 instead of the consent page, and (b) even if the player opens /squeek-connect/ by hand and presses Continue, that same-origin GET again carries no Sec-Fetch-Site, so consented is false and the answer is 403 again.

There is no path on which such a client can obtain a code: the login is impossible for that browser class rather than consent-gated. Before 9d88f5c the same signed-in client was issued a code, so this is a regression, and AUDIT_REQUEST.md section 2 ('Browsers that send no fetch metadata always go through the consent page') states the opposite of the code.

Test '64b1ce06 #4' only covers site=null together with sec-fetch-mode: navigate, so the fully header-less navigation is untested. No security impact (fails closed).

Fix, preserving the one-click design: (1) when Sec-Fetch-Mode is absent, treat a GET whose Accept contains text/html as a navigation and redirect to /squeek-connect/ as line 117 does for navigate; (2) give the consent click a proof that does not depend on Fetch Metadata, e.g. make Continue a same-origin POST (form or fetch with credentials) to a small consent route that checks Origin === issuer (sent on POST by every browser) and the session cookie, then 303s back to authorize with a short-lived single-use consent nonce bound to the session hash that authorize accepts as equivalent to Sec-Fetch-Site: same-origin; add a test with a signed-in cookie and no sec-fetch-* headers asserting a 303 to /squeek-connect/ and a completed login.

Alternatively, document in section 2 that clients without Fetch Metadata cannot sign in and have the game show that message.

The consent gate treats Sec-Fetch-Site: none as 'the user's own navigation (a typed or bookmarked URL)' (AUDIT_REQUEST.md section 2).

Per the Fetch Metadata specification, browsers send 'none' for every navigation whose initiator is not a web origin: the address bar and bookmarks, but also any URL handed to the browser by another application (a link tapped in a native mail client, Discord/Telegram/Slack desktop or mobile apps, a PDF viewer, a QR scanner, an OS intent, or a native/Electron game build that opens the system browser).

The World session cookie is a top-level same-site cookie, so such a GET carries it. A third party who gets a signed-in player to open a prepared authorize link (with the third party's own code_challenge and state) therefore skips /squeek-connect/ entirely: lines 121-125 insert a squeek_auth_codes row for the victim's wallet and 303 the victim to the game with world_code and the attacker's world_state.

This is exactly the case the request asks to rule out ('any way to obtain a code for a signed-in victim without their click on World').

Impact is bounded: the code is delivered only to the victim's own browser at the fixed game origin and is PKCE-bound to the attacker's verifier, so the attacker cannot exchange it unless the game forwards the code somewhere the attacker can read; the victim's game tab does receive an authorization response with a state it did not create (the game's handling of a foreign state is outside this package).

The party the consent page is meant to protect the player from, the game operator, can also skip it from a native build. The designed flow never needs 'none': the Continue link on /squeek-connect/ is a same-origin navigation.

Fix: consented = site==='same-origin' (optionally also require sec-fetch-mode: navigate); a typed or bookmarked authorize URL then simply gets the one-click page like every game login. If consent is reworked into a same-origin POST (see the Fetch-Metadata-less finding), that change covers this one too. Update section 2 accordingly and change the 'none' branch of test '64b1ce06 #4' to expect the consent redirect and codes()==1.

Order inside authorize(): query validation (lines 109-110), then the per-client limiter 'squeek:authorize:'+ip (line 111; worker/app.ts line 201 maps it to allow('home',key), AUTH_LIMITER, 20 per minute per key per wrangler.jsonc line 52), then readSession (line 112, one D1 read), and only then the header-only consent decision (lines 115-118). A request that will be refused for lack of consent therefore still spends the victim's IP budget and costs a database read.

A GET subresource from any site ( or fetch(...,{mode:'no-cors'})) sends no Origin header, so the route's origin check at line 199 passes; the parameters are static and public (client_id, fixed redirect, any 43-char challenge, any 22-128-char state), so validation passes; the budget is spent although the request carries no cookie and is answered 401 at line 118.

Twenty such requests per minute from a page the signed-in player (or anyone behind the same NAT) has open leave that IP's own login navigation answered 429 RATE_LIMITED for the next minute, repeatable while the page stays open. The sibling checkout() route does it the other way round: it refuses a non-same-origin Sec-Fetch-Site at line 160 before touching its budget.

Impact is limited to the squeek login (other sign-in budgets use different keys) and needs the victim on the attacker's page, hence Low.

Fix: evaluate the consent condition first, before deps.allow and before readSession: when sec-fetch-site is present and not same-origin (or 'none' if still accepted), answer the 303 to /squeek-connect/ (navigate) or 403 immediately with no budget spent and no database read; spend the budget and read the session only for requests that can mint a code. The existing tests keep passing ('64b1ce06 #4' asserts only status and code count).

AUDIT_REQUEST.md section 1 row 4 says 'The token UPDATE now consumes the code on every attempt within its 60 s'. Only attempts that pass body validation at line 131 reach the consuming UPDATE at lines 135-145.

An attempt carrying the real, live code together with a different redirect_uri, client_id or grant_type, or a code_verifier that is not exactly 43 base64url characters, is answered 400 BAD_REQUEST before the database is touched, and the code stays usable until its expiry for a later well-formed exchange.

RFC 6749 only requires denial and revocation on reuse of a code, and a holder of the code without the verifier still cannot obtain a grant, so this is not a security defect: the wrong-verifier case (the one that matters) is spent as claimed. It is recorded so the game's specification and the disclosure are read as the exact behaviour: a wrong verifier spends the code, a malformed request does not.

If the broader statement is wanted, run the consuming UPDATE whenever b.code matches OPAQUE regardless of the other fields (bind redirect_uri and the computed challenge, or a sentinel when the verifier is malformed) and return 400/401 after it; add a test: mint, exchange with redirect_uri REDIRECT+'x' (400), then the correct exchange and assert 401 and consumed_at set.

The consuming UPDATE makes every exchange single-use and the second use answers 401 INVALID_GRANT at line 147. RFC 6749 section 4.1.2 adds that when a code is used more than once the server SHOULD revoke all tokens previously issued on it, because a second presentation means the code leaked (the game's landing URL carries world_code for 60 s).

As written, after a successful exchange a replay yields 401 and nothing else: the grant issued on the first exchange stays valid for up to an hour. Exploitability is very limited: whoever exchanges first needs the PKCE verifier, which lives only in the game client, so a party holding only the leaked code cannot obtain the grant in either order; the gap only matters if the verifier is also compromised, in which case revocation on reuse is a late signal.

Revocation also hands a code observer a one-shot way to log the victim's game out, so this is a design choice to record rather than a defect.

If the SHOULD is wanted: in token(), when rows[0] is empty, run UPDATE squeek_tokens SET revoked_at=?now WHERE token_hash=(SELECT token_hash FROM squeek_auth_codes WHERE code_hash=?hash AND token_hash<>'rejected') AND revoked_at IS NULL, still answering 401, and add a test that after exchange, exchange, the first grant's snapshot answers 401.

The render at lines 55-59 tests order first and owned second. When checkout/state returns a pending order for this request key together with owned=true (the same wallet paid another order for the same sku, e.g. two tabs or two game purchase keys, the 'first payment to land wins' case disclosed in Submission28), the page shows the original order and the 'Sign payment of 200 GOLD' button instead of the ALREADY_OWNED notice.

Pressing it runs operate(true) at lines 35-41, which ignores latest.owned and requests a GOLD challenge; the server refuses it with ALREADY_OWNED (economy-ledger.ts line 268 in createEconomyGoldChallenge, and SQUEEK_ONE_TIME_SQL inside the debit batch would refuse the payment anyway), so no GOLD is taken. The gap is a flow one: the page asks the player to confirm a payment the server will always refuse while its own data (owned) already says so.

Fix: in the pending-order branch, when data.owned is true render the ALREADY_OWNED status (keeping the order id for reference) and no button; in operate(true) throw ALREADY_OWNED before requesting a challenge when latest.owned is true.