Prevenir la entrada de datos incorrectos

Question

¿Es una buena práctica delegar completamente la validación de datos a las limitaciones del motor de base de datos?

La validación de datos de la aplicación no evita la inserción no válida desde otro software (posiblemente escrito en otro idioma por otro equipo).Al utilizar restricciones de base de datos, reduce los puntos en los que debe preocuparse por datos de entrada no válidos.

Si pones validación tanto en base de datos como en aplicación, el mantenimiento se vuelve aburrido, porque hay que actualizar código para quién sabe cuántas aplicaciones, aumentando la probabilidad de errores humanos.

Simplemente no veo que esto se haga mucho, mirando el código de proyectos de software libre.

Answer 1

Es mejor, cuando sea posible, tener sus reglas de validación especificadas en su base de datos y usar o escribir un marco que haga que esas reglas aparezcan en su interfaz.ASP.NET Dynamic Data ayuda con esto y existen algunas bibliotecas comerciales que lo hacen aún más fácil.

Esto se puede hacer tanto para una validación de entrada simple (como números o fechas) como para datos relacionados como los restringidos por claves externas.

En resumen, la idea es definir las reglas en un lugar (la base de datos la mayor parte del tiempo) y tener código en otras capas que harán cumplir esas reglas.

Answer 2

Validar en el momento de la entrada.Valide nuevamente antes de colocarlo en la base de datos.Y tenga restricciones de base de datos para evitar entradas incorrectas.Y puede apostar que, a pesar de todo eso, los datos incorrectos seguirán ingresando a su base de datos, así que valídelos nuevamente cuando los use.

Parece que todos los días alguna aplicación web es pirateada porque hicieron toda su validación en el formulario o peor aún, usando Javascript, y la gente encontró una manera de evitarlo.Tienes que protegerte contra eso.

¿Paranoico?¿A mí?No, solo experimentado.

Answer 3

La desventaja de dejar la lógica a la base de datos es que aumenta la carga en ese servidor en particular.Los servidores web y de aplicaciones son comparativamente fáciles de escalar hacia afuera, pero una base de datos requiere técnicas especiales.Como regla general, es una buena idea poner la mayor cantidad de lógica computacional en la capa de aplicación y mantener la interacción con la base de datos lo más simple posible.

Dicho esto, es posible que su aplicación no tenga que preocuparse por problemas de escalabilidad tan importantes.Si usted es cierto esa carga del servidor de la base de datos no será un problema en el futuro previsible, luego siga adelante y ponga las restricciones a la base de datos.Tiene toda la razón en que esto mejora la organización y la simplicidad de su sistema en su conjunto al mantener la lógica de validación en una ubicación central.

Answer 4

Hay otras preocupaciones además de la inyección SQL con entrada.Debe adoptar la postura más defensiva posible cada vez que acepte comentarios del usuario.Por ejemplo, un usuario podría ingresar un enlace a una imagen en un cuadro de texto, que en realidad es un script PHP que ejecuta algo desagradable.

Si diseña bien su aplicación, no debería tener que verificar laboriosamente todas las entradas.Por ejemplo, podría utilizar una API de Forms que se encargue de la mayor parte del trabajo por usted y una capa de base de datos que haga prácticamente lo mismo.

Este es un buen recurso para la comprobación básica de vulnerabilidades:

http://ha.ckers.org/xss.html

Answer 5

Ya es demasiado tarde cuando los datos llegan a su base de datos para proporcionar una validación significativa para sus usuarios y aplicaciones.No quieres que tu base de datos funcione todo la validación ya que eso ralentizará bastante las cosas y la base de datos no expresa la lógica con tanta claridad.De manera similar, a medida que crezca, escribirá más transacciones a nivel de aplicación para complementar las transacciones de su base de datos.

Answer 6

Yo diría que es potencialmente una mala práctica, dependiendo de lo que suceda cuando falla la consulta.Por ejemplo, si su base de datos puede arrojar un error que fue manejado inteligentemente por una aplicación, entonces podría estar bien.

Por otro lado, si no pones ninguna validación en tu aplicación, es posible que no tengas datos incorrectos, pero es posible que los usuarios piensen que ingresaron cosas que no se guardan.

Answer 7

Implemente tanta validación de datos como pueda al final de la base de datos sin comprometer otros objetivos.Por ejemplo, si la velocidad es un problema, es posible que desees considerar no usando claves foráneas, etc.Además, algunas validaciones de datos solo se pueden realizar en el lado de la aplicación, por ejemplo, garantizar que las direcciones de correo electrónico tengan dominios válidos.

Answer 8

Otra desventaja de realizar la validación de datos desde la base de datos es que a menudo no se valida de la misma manera en todos los casos.De hecho, a menudo depende de la lógica de la aplicación (roles de usuario) y, a veces, es posible que desee omitir la validación por completo (trabajos cron y scripts de mantenimiento).

Answer 9

Descubrí que realizar la validación en la aplicación, en lugar de en la base de datos, funciona bien.Por supuesto, entonces toda la interacción debe realizarse a través de su aplicación.Si tiene otras aplicaciones que funcionan con sus datos, su aplicación deberá admitir algún tipo de API (con suerte, REST).

Answer 10

No creo que haya una respuesta correcta, depende de su uso.

Si va a tener un sistema muy utilizado, con la posibilidad de que el rendimiento de la base de datos se convierta en un cuello de botella, entonces es posible que desee trasladar la responsabilidad de la validación al front-end, donde es más fácil escalar con múltiples servidores.

Si tiene varias aplicaciones interactuando con la base de datos, es posible que no desee replicar y mantener las reglas de validación en varias aplicaciones, por lo que la base de datos podría ser el mejor lugar.

Es posible que desee una pantalla de entrada más elegante que no solo le muestre al usuario advertencias de validación cuando intenta guardar un registro, tal vez desee validar un campo después de que se hayan ingresado datos y pierda el foco;o incluso mientras el usuario escribe, cambiando el color de fuente a medida que la validación falla o pasa.

También relacionadas con las restricciones están las advertencias de datos sospechosos.En mi aplicación tengo restricciones estrictas en la base de datos (p. ej.alguien no puede comenzar un trabajo antes de su fecha de nacimiento), pero luego en el front-end tiene advertencias sobre datos que posiblemente sean correctos, pero sospechosos (p. ej.un niño de ocho años que empieza a trabajar).