An MCP client receives an authorization URL from a server that uses a data: scheme and contains shell metacharacters. After refusing to open it, what else does the security best practices guidance recommend?
Select an answer to reveal the explanation.
Short Explanation
Turning the burglar away is step one — writing down what he looked like is step two. The guidance asks clients to log suspicious authorization URLs for security monitoring. A malicious server that tried once will probably try again, and you want a record when it does.
Full Explanation
The security best practices on OAuth authorization URL validation say clients MUST only allow http and https schemes, with http only for loopback during development, MUST reject the javascript, data, file and vbscript schemes and other dangerous schemes, and MUST NOT open URLs through shell commands. Under input sanitization, clients MUST sanitize and validate all URLs received from MCP servers, which includes strict parsing, rejecting characters a shell might interpret, considering dedicated sanitization libraries, and logging suspicious authorization URLs for security monitoring. A logged rejection gives security teams evidence that a configured server is behaving maliciously. Retrying through a shell with escaping reintroduces the command injection path the rule forbids outright; escaping is fragile and the requirement is to avoid the shell entirely. notifications/message is a server-to-client log notification in a deprecated feature; clients do not send it, and reporting back to a hostile server accomplishes nothing. Rewriting a data-scheme URL into an https URL means the client invents a destination the server never offered, which could send the user anywhere. Exam caveat: web-based clients SHOULD also deploy a Content Security Policy so a missed script-scheme URL cannot execute inline script. Operational check: feed the client a crafted authorization URL and confirm it is rejected, never passed to a shell, and recorded in the client's security log.