Si está realmente seguro de que el código inyectado solo puede ser ejecutado por la misma persona que lo inyectó, entonces podría clasificarse como "self-XSS", como se menciona en un comentario a tu pregunta. Al parecer, para aprovechar que un atacante necesita confiar en la ingeniería social, intenta engañar a otros usuarios para que inyecten el código ellos mismos y lo ejecuten.
EDITADO PARA AGREGAR ESCENARIO CSRF
La respuesta de Anders sugiere un escenario CSRF pero no estoy de acuerdo con eso (y aún no tengo suficiente reputación para comentar allí). Sin embargo, me acabo de dar cuenta de que una vulnerabilidad CSRF puede ayudar al atacante a explotar su XSS. Anders sugirió usar CSRF para iniciar sesión como el atacante y redirigir a su página que había sido infectada previamente. De esta manera te encontrarás ejecutando js arbitrarios, pero estás registrado como el atacante y ejecutando js en la página privada del atacante. Eso me parece inútil. La opción supuestamente correcta sería utilizar CSRF para inyectar el código malicioso directamente en la página de la víctima. Funcionaría de esta manera:
- la víctima ha iniciado sesión en tu sitio web
- la víctima visita un sitio web malicioso que usa CSRF para inyectar el XSS en su propia página privada (por ejemplo, una solicitud POST a un formulario que cambia su configuración de perfil y coloca js en el campo vulnerable)
- la víctima visita su propia página privada y ... ahora hay js inyectados allí
Por supuesto, esto requiere que el formulario en su sitio web utilizado para inyectar js sea vulnerable a CSRF (por ejemplo, porque el formulario no requiere un token secreto oculto), por lo que un atacante puede forzar a la víctima a realizar una solicitud a su Sitio web con graves consecuencias sin el consentimiento de la víctima, por ejemplo, cambiar la configuración, las contraseñas o, en este caso específico, inyectar js. Lea sobre CSRF si necesita comprender más.