It would be of use to VRChat world creators using custom web services to introduce an HMAC-signed web request feature. This would allow creators to verify that a web request comes from within VRChat (+ within a specific VRChat world) to prevent API misuse by bad actors. This way, API services can verify requests using a dynamic value without enabling runtime construction of untrusted VRCUrls (otherwise I'd just attach a query parameter).

It's not really that complex to implement on either end (imo) and is a well-established web standard practice. World creators would only need to specify some secret (since the stakes here are pretty low, you could just generate a UUID in the editor to make it easier for creators) and string/image loading requests would have the appropriate headers set.

Data exfiltration would likely not be a concern because it would be incredibly impractical to pack any meaningful data into an HMAC signature. Additionally, APIs can simply choose to ignore any authentication headers, maintaining compatibility with existing web services. It would also be impractical to identify the user making the request or the world making the request (without the HMAC secret value). Since VRChat world bundles are encrypted now, it would be difficult to extract the secret value from them.

Example use case: I have a fountain that players can throw coins into. I want to keep a counter that tracks the number of coins thrown into the fountain across all instances. I create an API with an addCoin route that increments the counter. A user finds the URL of my API endpoint and spams the server with requests, making the counter's value invalid. Since I have to specify the URL in the editor, I can't add a dynamic secret value and I cannot determine which requests are legitimate.

tldr: optionally sign web requests so that my API can accept requests from within my VRChat world only