Quiero saber por qué llamar a una base de datos desde el extremo frontal se considera una mala práctica para la seguridad.
Es realmente tan malo justificar la construcción de una capa de aplicación con todos sus inconvenientes: ¿costos, rendimiento, tiempo de desarrollo?
No estoy seguro de a qué te refieres exactamente. La separación de capas como la lógica empresarial y de la aplicación y el acceso a los datos no se trata tanto de la seguridad como de la capacidad de mantenimiento. Se hace para hacer que el código sea utilizable y poder hacer cosas como cambiar la base de datos que usa sin tener que volver a escribir la aplicación por completo.
También hace que la seguridad sea más fácil, ya que puede asegurar el DAL para garantizar que las llamadas SQL no puedan ser abusadas, pero lo mismo se puede hacer con un poco más de esfuerzo, incluso si su código es completamente plano.
Entonces, su premisa inicial de que es una mala práctica de seguridad no es exactamente correcta, es simplemente una mala práctica de programación en general. El hecho de que hace que la seguridad sea más difícil de implementar bien es solo un efecto secundario del mal diseño general.
Una conexión de base de datos le permitirá al usuario hacer prácticamente cualquier cosa que le guste a la base de datos, siempre que tenga los derechos de acceso. Abra una conexión directamente a Internet, y lo único que impide que un usuario tenga acceso a la cuenta de administrador es el secreto de la contraseña de la cuenta de administrador. En su mayor parte, no verá un sistema de base de datos creado teniendo en cuenta este tipo de acceso, por lo que no verá protecciones en la base de datos que están diseñadas para este uso.
Dado el acceso de administrador y la conectividad, un pirata informático puede:
Entonces ... la pregunta de retorno es: ¿cuál es el propósito de la base de datos y cuánto importa la integridad? Si esta es una base de datos de prueba para un proyecto de un estudiante, es posible que le interese más la máquina que la base de datos. Pero en la mayoría de las aplicaciones, la información en la base de datos y su validez, disponibilidad y confiabilidad son el corazón del sistema. Olvídelo o pierda su confianza en él y, en muchos casos, ya no tiene un negocio en funcionamiento.
Sin embargo, hablando como un desarrollador web, el principal factor para tener una aplicación web aún no es la seguridad, es su funcionalidad. La gente no tiende a pensar en SQL, por lo que necesita una interfaz que permita a un usuario menos técnico ver y manipular los datos de manera que el usuario pueda comprenderlos. Una vez que admite, incluso en un caso, que necesita un servidor web o un servidor de aplicaciones para convertir los datos en una página legible por el usuario, entonces ha eliminado la necesidad de aumentar los costos de almacenamiento en etapas del servidor de aplicaciones. Y una vez que ha invertido tiempo y energía en desarrollar formularios u otros mecanismos de entrada de datos que el usuario promedio puede usar, ha invertido lo suficiente en el sitio en general, que hacerlo correctamente, con prácticas de seguridad sólidas, es una inversión inteligente, no solo para proteja sus datos, pero para proteger el valor de la inversión en la creación de la aplicación.
No estoy muy claro a qué te refieres con "front-end" pero si estás hablando de disparar comandos de base de datos directamente desde el lado del cliente de una aplicación web, esto sería muy malo.
Cualquier javascript del lado del cliente que tenga puede ser fácilmente modificado o eludido por completo, lo que significa que cualquier comando que ejecute desde el lado del cliente podría modificarse para hacer lo que quiera un usuario malicioso. Por ejemplo, podrían cambiar su comando de: SELECT * FROM Products a DELETE Products
Además de eso, es una mala idea tener acceso a su servidor de base de datos desde Internet. Normalmente, usted desea tener un servidor web al que se pueda acceder desde Internet y luego su servidor de base de datos esté disponible para el servidor web.
Lea otras preguntas en las etiquetas secure-coding sql-server