Voy a responder tu pregunta con un aluvión de otras preguntas.
¿Realmente su aplicación necesita llegar a Internet abierto? ¿O simplemente puede existir en la intranet de una empresa?
La mayoría de los 'exploits java' son simplemente formas en que la caja de arena de java puede ser eliminada y de poca importancia para las aplicaciones java legítimas, ya que en realidad es una comparación de manzanas y naranjas.
La mayoría de las "vulnerabilidades del navegador" son de una vena similar (obtener acceso a un sistema u otros datos en el navegador, al salir de la zona de pruebas del navegador). Chrome ayuda un poco en esto.
Dicho esto, la mayoría de las vulnerabilidades de 'servidor web' se basan en poder ejecutar su propio código o extraer datos que no debe hacer.
Si tiene una aplicación java que habla directamente con un back-end C a través de sockets, ¿qué tan bloqueada está su aplicación C? El potencial de daño puede ser bastante alto (ya que, dependiendo de su software, tiene el potencial de explotaciones en la cadena de cable o incluso la ejecución directa de código, así como tener disponible toda la memoria de los procesos).
Esto requeriría un atacante más sofisticado.
Por otra parte, si tiene un servidor web COTS, corre el riesgo de que un atacante menos experto pueda correr alrededor de sus sistemas.
Y todas las reescrituras están condenadas a cometer los mismos errores que cometió el código original (incluso si el programador original todavía existe).
Personalmente me mantendría alejado de node.js simplemente porque es una tecnología inmadura en comparación con otras opciones.
¿Cuál es el costo potencial del compromiso?
¿Cuál es el resultado potencial para el compromiso?
¿Quién tendría un interés personal en comprometer dicho sistema?
¿Es el robo de datos o la manipulación de datos lo que más perjudicará?