inquietudes acerca de las llamadas a la API REST desde múltiples servidores

3

Hay una aplicación web maestra que necesita llamar a API REST desde servidores de otras aplicaciones. Puedo pensar en dos maneras de lograrlo:

a). llame a las API en el extremo frontal de la aplicación maestra (javascript)

// javascript code of master application
$.ajax(api_server1_url,{
  ...
})

b). Llame a las API en el servidor de la aplicación maestra

// backend code of master application
call_api(api_server1_url)

Tanto a como b devuelven el resultado json para otros usuarios en la aplicación maestra.

Si tengo acceso al código y a los servidores de todas las aplicaciones mencionadas anteriormente, ¿es la opción a o la opción b una mejor práctica en cuanto a seguridad?

muy nuevo en seguridad, pero enumeraré lo que sé (no mucho ...): a tiene una vulnerabilidad de scripts entre sitios. Creo que es posible eliminarlo o limitarlo cambiando el código en las aplicaciones de la API, pero tomará un esfuerzo.

Por eso prefiero la opción b. Aunque el código en los servidores de API aún debe actualizarse para evitar ataques, pero debería ser más fácil que la opción a. Solo permitir que la ip de la aplicación maestra acceda a los servidores API debería ser suficiente.

Así que mi pregunta es:

¿Mi suposición sobre b es mejor un derecho? De lo contrario, ¿qué medidas de seguridad necesito implementar en los servidores API?

Gracias por cualquier entrada.

    
pregunta odieatla 19.02.2016 - 02:36
fuente

2 respuestas

1

Actualización de la pregunta:

En la arquitectura de aplicaciones, ¿cuál es la forma más segura de delegar llamadas entre las API de Javascript:

  1. Para permitir que el cliente final llame directamente a la API de alojamiento; o
  2. Para delegar la llamada del cliente final a través de un servidor front-end.

Contexto posible: esta preocupación podría ser más aplicable a Node.js donde la lógica de la aplicación se implementa a través de Javascript. De lo contrario, todavía no estoy seguro de entender la pregunta correctamente ...:

Respuestas rápidas:

Aquí hay algunos enlaces sobre cómo proteger las API de REST, con suerte para ayudar a enfocar la pregunta un poco, pero no estoy seguro de si esta es la pregunta:

Respuestas: la arquitectura de múltiples niveles no es seguridad:

La arquitectura de la aplicación es muy diferente de " Desarrollo seguro de la aplicación ".

No importa cómo cree / estructure / divida la funcionalidad, no protegerá la aplicación, sino que solo permitirá el marco básico para que pueda asegurarla .

En tu pregunta, en realidad estás discutiendo " Arquitectura multinivel ".

Y, si no se ha diseñado correctamente, no se puede asegurar la aplicación.

Estos son los principios fundamentales de la arquitectura de aplicaciones multinivel, a los que creo que se refiere:

  1. Acople el Lógica de presentación y el Cliente de forma flexible a la Lógica de integración y negocios subyacente: desacople completamente de toda la Lógica de datos.
  2. Acoplar sin apretar la lógica de integración (interfaces B2B, etc.) a la lógica empresarial, completamente desacoplada de la lógica de datos.
  3. Acoplar libremente el negocio a la lógica de datos.
  4. Nunca permita el acceso desde un nivel al nivel superior, solo UN nivel abajo (Presentación a la empresa y Acceso de la empresa a los datos, pero no a la Presentación directamente a los datos, ni a la Integración directa a los datos, pero la Integración a la empresa es bien.

Sin embargo, incluso cuando se implementa correctamente, debe proteger las interfaces entre cada nivel, de lo contrario, es tan vulnerable como si todo estuviera funcionando en el cliente.

    
respondido por el elika kohen 19.02.2016 - 03:31
fuente
1

Yo diría que B es objetivamente más seguro dado un cierto contexto. Específicamente, si la API de terceros requiere un inicio de sesión o una clave de API, el cliente (navegador) no debe tener acceso a esa información.

    
respondido por el user52472 13.02.2017 - 19:59
fuente

Lea otras preguntas en las etiquetas