Asegure una API REST de acceso público

El primer pensamiento que viene a la mente es utilizar sesiones o configurar algo en su página para registrar las IP de las conexiones entrantes y solo permitir que la API REST responda a las IP que han accedido recientemente a su página principal. Esto no evitará todos los casos, pero significa que alguien debe al menos tener que acceder periódicamente al sitio principal para hacer uso de la API REST.

Fundamentalmente, sin embargo, si no se requiere que los usuarios se autentiquen, entonces no hay nada que impida que un destripador de pantalla extraiga datos de su sitio de manera efectiva. La API de REST debe hacer cumplir las reglas comerciales y, por lo tanto, la API de REST debería ser su sitio web y la página que lo usa debería simplemente proporcionar formato para la pantalla.

Si esto es para aplicaciones nativas , puedes probar lo siguiente,

1. Almacene una clave de acceso en su paquete de aplicaciones. Nadie más que el propietario de la aplicación (usted mismo) puede tener esto.
2. Cambie su API para que solo tengan éxito las solicitudes con la clave de acceso establecida en el encabezado.
3. Use HTTPS para que nadie pueda leer la clave de acceso cifrada.

Si no usa HTTPS, aún puede codificar manualmente la clave de acceso con algo en el encabezado (solo el servidor y la lógica de la aplicación saben cómo hacerlo) para que el hombre del medio no pueda pretender ser su aplicación.

Si esto es solo para aplicaciones web,

Primero sugeriría envolver la aplicación web pura dentro de una aplicación nativa (a.k.a. Aplicación híbrida) para que pueda lograr la protección descrita anteriormente, al agrupar una clave secreta dentro de la aplicación. El desarrollo de una aplicación nativa con una sola vista web no debería costar demasiado.

Sin embargo, si eso no es posible, entonces su aplicación sigue siendo una aplicación web pura, aquí hay una opción potencial,

1. Cuando el servidor sirve a la aplicación web, proporcione una clave de acceso.
2. Cuando la aplicación web realiza una llamada a la API, debe proporcionar una versión con hash de la clave de acceso.
3. La forma en que los hashes de la aplicación web depende de la lógica que se implementa en los códigos minificados + ofuscados.
4. La API de backend luego valida el hash aplicando la misma lógica oculta a la clave de acceso almacenada para calcular el hash y ver si coincide.
5. Puede cambiar la lógica oculta y la clave de acceso tan frecuentemente como sea necesario para reducir la posibilidad de que alguien obtenga el hash correcto.

Esto, por supuesto, no es a prueba de balas, pero como usted sabe, no existe una seguridad perfecta y esto probablemente logra el propósito (y es de esperar que se ajuste a los requisitos). Sin embargo, diría que ir híbrido es más rentable.

Esto podría ayudar. Hay muchas cosas que puedes hacer para asegurar tu servicio de descanso. Uno es CORS y usa PUT / Delete ya que estos encabezados no pueden configurarse en varios dominios. enlace