Estás pidiendo una respuesta desde un punto de vista de seguridad. Sin embargo, hay más de un punto de vista de seguridad según el modelo de amenaza que tenga en mente.
Si su modelo de amenaza es un atacante que intenta comprometer su servidor al realizar solicitudes a su servidor, diría que no importa el manejo de las solicitudes que especifican una dirección IP en el encabezado del host en lugar de un nombre de dominio.
Es muy poco probable que su manejo actualizado de las solicitudes con una dirección IP en el encabezado del host lo abra a nuevas formas de comprometer el servidor. Además, los ataques contra la aplicación completa en su nombre de dominio primario funcionarán de manera indiferente, ya que el atacante solo puede poner ese nombre de dominio en el encabezado del host.
Si su modelo de amenaza es un atacante que intenta atraer a sus usuarios a una trampa dándoles enlaces a nombres de dominio no oficiales que apuntan a su servidor, entonces recuerde que un atacante podría lograr lo mismo al configurar un proxy en su propia IP, lo que modifica el encabezado del host antes de pasarle la solicitud, y podrían realizar cambios en las respuestas antes de devolvérselas al usuario.
Como tal, tampoco existe un riesgo significativo en esta área. A menos que el atacante esté intentando realizar un ataque de phishing. Lo mejor que puede hacer para asegurarse de que los usuarios no caigan en un ataque de phishing es tener solo un nombre de dominio legítimo que necesitan para poder reconocer. Redirigir todas las solicitudes con una IP o un nombre de dominio secundario en el encabezado del host al dominio legítimo es un enfoque fácil para el usuario.
Sin embargo, puede ser un poco demasiado fácil de usar. Después de todo, no se supone que los usuarios vengan a través de una URL usando IP o nombre de dominio secundario en primer lugar. Por lo tanto, la redirección podría llevar a una situación en la que no se presta suficiente atención a las URL que no utilizan el dominio adecuado, ya que "simplemente funcionan". Si los usuarios se acostumbran a una variedad de dominios y direcciones IP que se usan en las URL, esos usuarios serán un objetivo más fácil para el phishing.
Hacer que los dominios e IP secundarios produzcan un mensaje de error que incluya un enlace al dominio adecuado puede ayudar a garantizar que tanto los usuarios como los desarrolladores estén conscientes de que las URL deben contener el dominio principal y nada más. Servir a las páginas de error con un código de error 4xx adecuado produciría resultados más predecibles si cualquier software automatizado está accediendo a URL incorrectas. Sin embargo, servir las páginas de error con un código 200 puede facilitar que los motores de búsqueda encuentren el contenido en caso de que haya enlaces externos fuera de su control, que apuntan a la IP o dominios secundarios.
Independientemente de si elige el código 2xx, 3xx o 4xx para esas respuestas, la configuración más limpia para lograrlo sería una vhost independiente en la configuración del servidor web. Una respuesta anterior da un ejemplo de cómo se podría lograr esto. Otros servidores web también pueden hacerlo.
Otro modelo de amenaza a tener en cuenta son las solicitudes a su aplicación que intentan engañar a su aplicación para que use un nombre de dominio incorrecto que se pasa a través del encabezado del host en el contenido generado dinámicamente. Si el nombre de dominio del encabezado de host solo se usa para generar una respuesta a la solicitud que utilizó un encabezado de host incorrecto en primer lugar, entonces esto no es una preocupación importante. Sin embargo, si su aplicación utiliza el encabezado del host para generar las URL que luego se mostrarán en los correos electrónicos o en su base de datos, esto es motivo de preocupación.