During OAuth discovery, a malicious MCP server supplies an authorization endpoint that is a javascript-scheme URL whose script sends the user's cookies to an attacker's site. How should the client handle authorization URLs like this?
Select an answer to reveal the explanation.
Short Explanation
A script-scheme link isn't a web address, it's a script wearing a URL costume. You keep an allowlist of https only, with plain http just for localhost during development, and you never pipe a URL through a shell. Otherwise you've built the attacker an XSS or command-injection button.
Full Explanation
The security best practices on OAuth authorization URL validation say clients MUST only allow http and https schemes for authorization URLs, with http acceptable only for loopback addresses during local development and https required for production authorization servers. Clients MUST reject the javascript, data, file and vbscript schemes and other dangerous schemes, SHOULD prefer allowlist validation over blocklists, and MUST NOT use shell commands such as the Windows command shell, sh or PowerShell to open URLs. Passing a script-scheme URL to a window-opening API can execute attacker script in the client's context, which is the documented cross-site scripting path; a new window does not make it safe. Handing the URL to a shell lets metacharacters be interpreted as extra commands, the documented remote code execution path. Trusting the value because metadata lists it misses the point, since the metadata itself comes from the server the attacker controls in this scenario. Exam caveat: in proxy architectures, cross-site scripting combined with stdio process spawning can escalate to full system compromise, which is why web-based clients also SHOULD deploy a Content Security Policy. Operational check: feed the client authorization endpoints that use the javascript and data schemes or shell metacharacters, and confirm each is rejected and nothing is executed.