Haciendo un repositorio de API privado vs público

1

Por lo tanto, actualmente estoy trabajando en la API de una aplicación que atenderá a muchos usuarios. Actualmente, la única información "confidencial" que se almacena mediante la API son los correos electrónicos y los nombres de los usuarios. La aplicación permite a los usuarios formar equipos (que pueden ser privados). La API atiende solicitudes provenientes de Slack y también de un sitio web de cliente. La API también recopila los metadatos sobre las comunicaciones de los usuarios con holgura.

Suponiendo que no se expongan secretos en la base de código, ¿sería correcto mantener el repositorio público?

Los principales argumentos para hacerlo público son:

  1. Mantener el código abierto del proyecto.
  2. Puede ser un recurso de aprendizaje GraphQL útil.
  3. Acceso a herramientas de flujo de trabajo que solo son gratuitas para proyectos de código abierto.
  4. Obtenga ayuda de la comunidad para encontrar y parchar exploits.

Los principales argumentos en contra de hacerlo público son:

  1. Si hay algo que perdimos u olvidamos para asegurar, podría explotarse.
  2. La gente descubriría cómo funciona internamente y quizás intente alterar las cosas que aún no están validadas por completo.
  3. Si alguna vez somos descuidados y cometemos accidentalmente algo por debajo de la media que también podría crear problemas.

¿Cuál es el mejor enfoque aquí? Gracias por cualquier ayuda.

    
pregunta TheSabby 11.02.2018 - 14:35
fuente

1 respuesta

0

Creo que estás de acuerdo en hacer de este un repositorio público siempre que se cumplan las siguientes condiciones:

  1. No se guardan secretos de aplicación como claves o certificados en el repositorio.
  2. No se mantiene información confidencial o de identificación personal, como nombres de usuarios, direcciones de correo electrónico, contraseñas, etc. en el repositorio.
  3. No hay algoritmos que, de ingeniería inversa, puedan conducir a la exposición o exfiltración de cualquiera de los anteriores en el sistema de tiempo de ejecución. Por ejemplo, la ingeniería inversa es una rutina de cifrado o un protocolo que podría exponer un nombre de usuario y una contraseña.

Suponiendo que se cumpla un factor importante que no se debe pasar por alto es asegurarse de que su aplicación esté diseñada para protegerse de la intrusión. Esto incluiría la autenticación del usuario, asegurándose de que el front-end solo se comunique con el back-end a través de la API (es decir, no use directamente los servicios del backend, como hacer una llamada db desde el frontend), usando protocolos seguros (como HTTPS) para proteger el canal de comunicaciones. , y garantizar que el sistema operativo y cualquier otro servicio que esté utilizando se actualicen regularmente sobre los parches de seguridad.

    
respondido por el Jim Medlock 11.02.2018 - 14:50
fuente

Lea otras preguntas en las etiquetas