¿Mi UI necesita estar segura si mi API lo es?

Si su API es sólida, entonces la verdadera vulnerabilidad se relaciona con si puede o no estar seguro de que el usuario es quien dice ser.

Un vector de ataque se llama falsificación de solicitud entre sitios ("CSRF" o "XSRF"). Básicamente, alguien que se hace pasar por otro usuario y realiza solicitudes a su servidor.

Cuando establece una sesión (que contiene los roles para un usuario determinado), debe asegurarse de que nadie más pueda secuestrar esa sesión. Esto se hace normalmente configurando una cookie única en la máquina del usuario que es " enlace " (es decir, una cookie que el cliente -junto a JS no debería poder manipularlo), luego asegúrese de que esa cookie sea la misma en las solicitudes posteriores.

Aquí hay un módulo de nodo destinado a fortalecer el servidor web con protección CSRF, entre otras medidas de seguridad, que vale la pena analizar: enlace

Re: específicamente la API, aquí hay un muy interesante de alguien hackeando GitHub .

Esto probablemente va más allá de sus necesidades de seguridad, pero tenga en cuenta que cualquier extensión de Chrome con los permisos correctos puede alterar el lado del cliente de tal manera que rompa su modelo de seguridad (al enviar datos fuera del sitio o cambiar el UI, por ejemplo).

Creo que estás en el camino correcto. Mientras la API sea segura y no permita un comportamiento incorrecto, entonces no hay forma de que la UI sea manipulada para causar un mal comportamiento directamente, al menos en lo que concierne a la aplicación.

Los problemas comienzan cuando te das cuenta de que, desde la perspectiva del usuario, no se puede confiar en la interfaz de usuario. Si es posible manipular lo que ve el usuario, entonces es posible hacer que ingresen información incorrecta al inducir a error su entrada. Del mismo modo, la fuga de información de la interfaz de usuario puede o no ser un problema en su contexto.

No tendrá que preocuparse por que las explotaciones masivas rompan las reglas comerciales, ya que la API no lo permitirá, pero aún tiene preocupaciones de seguridad en relación con la experiencia del usuario final.

En teoría, es suficiente para que solo la API sea segura, como en el caso de las aplicaciones cliente-servidor típicas en las que el usuario utiliza un cliente de su elección y es el problema del usuario si se explota el cliente.

Sin embargo, en el caso de un sitio web, dado que usted proporciona el cliente (la interfaz web), es su responsabilidad garantizar que terceros no puedan explotarlo una vez que el usuario haya iniciado sesión utilizando técnicas como XSS y CSRF.

Lamentablemente, no puede restringir la información de un usuario de manera efectiva una vez que llega a la computadora cliente. En otras palabras, si entiendo correctamente que está enviando un archivo JS con código o información que no desea que el usuario pueda leer a menos que sean de roles específicos, entonces no podrá lograr ese objetivo . Deberá filtrar la información en el servidor antes de enviarla al cliente. Esta puede ser una tarea que lleva mucho tiempo comprobar siempre los roles de los usuarios antes de enviar datos. Esto requiere más llamadas al servidor a medida que el usuario realiza ciertas tareas que requieren información. Pero creo que esas acciones son necesarias para garantizar que la información sea accesible solo por los usuarios correctos.

Minified js no proporciona mucha ofuscación una vez que se ha enviado al usuario.