¿Es crítico que la API REST devuelva exactamente el mismo contenido que en la base de datos NoSQL?

Question

¿Es crítico que la API REST devuelva exactamente el mismo contenido que en la base de datos NoSQL?

#1 de Jonah Benton (2 votos)

2

En el pasado, me enseñaron que el esquema de la base de datos es crucial y no debería exponerse de ninguna manera para que los usuarios no puedan inyectar el sistema y robarle algo. Sin embargo, la mayoría de los casos que he escuchado se refieren a funciones de inicio de sesión que un pirata informático intenta actuar como otro usuario para obtener su privilegio en el sistema. No estoy seguro de si la situación sigue siendo la misma cuando la base de datos backend cambia a NoSQL.

Si el esquema sigue siendo crucial y debería mantenerse en secreto, ¿deberíamos usar siempre claves diferentes entre la respuesta de la API y la base de datos? Por ejemplo, product_name y db_prod_name . ¿Y deberíamos hacer siempre la estructura diferente entre la respuesta de la API y la base de datos NoSQL? ¿Qué pasará si devolvemos directamente el registro JSON de la base de datos NoSQL a la API?

El tema ¿Está bien revelar los nombres de las tablas de la base de datos? debería ser diferente para mí ya que mi pregunta es sobre la base de datos NoSQL , como AWS DynamoDB y MongoDB. Supongo que la estrategia de defensa puede ser diferente debido a que las características entre SQL y NoSQL son diferentes.

injection nosql

pregunta user1802604 31.07.2018 - 11:40

fuente

1 respuesta

Lea otras preguntas en las etiquetas injection nosql

¿Existe EAP como un protocolo de autenticación independiente o solo como marco? ¿Cuál es la forma más segura de usar Bitlocker con TPM?

score 2 · Accepted Answer

Primero, mantener un esquema en secreto no es una parte útil de ninguna postura de defensa. Para las bases de datos SQL, la prevención de la inyección de SQL implica una serie de técnicas: varios bits de configuración de base de datos, el uso de declaraciones preparadas, el saneamiento de entradas no confiables, todas practicadas por proyectos de código abierto, cuyo esquema SQL es público. De manera similar, aunque los DBs sin esquemas no tienen esquemas fijos, las técnicas relacionadas se aplican cuando se persisten datos que no son de confianza. En cualquier caso, mantener el esquema en secreto es innecesario si se usan esas otras técnicas, y si no lo son, el secreto probablemente no ayude.

La razón para mantener un esquema y nombres de campo separados entre la base de datos y la API tiene que ver con la administración de cambios.

Tu aplicación consume tu base de datos. Otras aplicaciones, que no están bajo su control, consumen su API.

Es relativamente fácil cambiar su esquema y ajustar su aplicación a él. Es difícil, doloroso y en muchos casos inaceptable forzar cambios de última hora en los consumidores de su API.

Por lo tanto, cree una superficie API que tenga sentido para sus clientes, y luego mantenga como detalle de implementación su esquema interno y detalles de la base de datos. Al principio, esto parece un esfuerzo desperdiciado, pero la ruta del éxito para las API implica estabilidad para sus clientes. Invierte en ello por adelantado.