To be fair, I think this is more a problem with overly aggressive / protective security software. When a user browses through folders in Share, the UI may need to load / save preferences (e.g. list mode, sort order, favorites) for the user. It does this by calling a backend API which needs to contain the identity of the user for which preferences are to be handled - technically, the same API can be used by admins to access / change preferences of other users, so the URL is right to include the user name.
There is no way to "fix" this in Share - you would have to patch both the backend API and any of the user interface components relying on it to change its behaviour, e.g. rely only on the currently authenticated user and prevent the caller from ever specifying a specific / other user for which to handle preferences.
