breaking: error on event.url, event.params and event.route access inside queries

[Nic-Polumeyv]

Closes #16416 with the error option which seems like the right approach to me. No hard feelings if it goes.

• event.url, event.params and event.route now throw on access inside query, query.batch and query.live, during SSR as well, matching how prerendering already treats url.search. The router runs on the client-sent x-sveltekit-pathname header to produce event.params and event.route.id, so hiding only url would leave the same footgun readable through params.
• The error message points at the migration, pass the value as a query argument. Reading trusted context from locals via handle still works, but since query requests no longer carry the page URL, handle sees the URL of the remote endpoint, so that context has to come from cookies or headers.
• command and form are unchanged when called directly. Remote functions called while a query is running inherit the restriction, since their results feed the same cached response.
• handleValidationError receives an event it can read url on, and prerendered data lookups inside queries resolve against the request URL rather than event.url.
• Query clients stop sending the x-sveltekit-pathname and x-sveltekit-search headers, and the server only applies them when they are present, which also fixes the query half of Remote functions fire during hydration with placeholder page.url, causing wrong server-side route resolution #15749.
• The test from feat: expose event.route and event.url to remote functions #14606 asserting queries can read the url is inverted, and the remote-functions docs bullet now documents the error.

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from ba309d4:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/ba309d449a1a43d944963d88e46a72870b65e476

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16452

Note

This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed.

[changeset-bot]

🦋 Changeset detected

Latest commit: ba309d4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Nic-Polumeyv]

The last commit changes how the server recognizes query requests. Instead of loading the remote module to check the function's flavor, it checks whether the client sent x-sveltekit-pathname, since query clients no longer send it. The error inside queries does not depend on this either way, it is enforced in run_remote_function by the function's own type. If you'd rather have the server check the flavor itself, reverting 0d06b02 restores that version.

[dummdidumm]

Not sure if that really can be abused but that last commit could have security implications - us not just checking ourselves anymore means an attacker could send along the header to force a different path and consequently break something in a security-relevant way.

[Nic-Polumeyv]

I assumed so too, but I couldn't construct an exploit. The header was never verified on any branch. On version-3 every remote request already takes url.pathname verbatim from x-sveltekit-pathname, so hooks and commands see whatever path the client claims today. The new invariant doesn't depend on it either, the url/params/route getters throw based on is_in_remote_query, which the query wrapper sets server-side, so a forged header on a query request changes nothing the query can observe. I'm not an expert on this though, so a few people should double-check my reasoning here.

[Rich-Harris]

thank you!