A file server exposes project files as file:// resources. A resources/read request arrives for a file-scheme URI that starts in the project folder, climbs two parent directories and names the system password file. What does the resources specification require of the server?
Select an answer to reveal the explanation.
Short Explanation
Those little dot-dot steps are someone walking backward out of your project folder and into the system's filing cabinet. You have to clean up the path and refuse anything that lands outside the tree you're exposing. Don't count on roots or cache hints to stop that walk.
Full Explanation
The resources specification's security considerations state that servers MUST validate all resource URIs and MUST sanitize file paths to prevent directory traversal attacks when serving file:// resources; access controls SHOULD be applied to sensitive resources and permissions SHOULD be checked before operations. A request containing dot-dot segments must be normalized and checked against the directory the server intends to expose, and anything resolving outside it is refused rather than read. Serving the file because resources are application-controlled confuses the user interaction model, which describes who chooses context, with authorization; it does not make an arbitrary path safe to read. Marking the result cacheScope private only limits who may reuse a cached copy, so the sensitive file would still be disclosed to the caller. Roots were informational even before 2026-07-28 deprecated them; they told a server where the client wanted it to work but never enforced which paths it could open. Exam caveat: a non-existent resource is reported with JSON-RPC error -32602, while a refused traversal should also never yield an empty contents array. Operational check: send resources/read requests with encoded and plain dot-dot sequences and confirm each is rejected without touching files outside the exposed tree.