JavaScript: validación del lado del cliente frente al lado del servidor

¿Qué es mejor hacer la validación del lado del cliente o del servidor?

En nuestra situación estamos usando

• jQuery y MVC.
• Datos JSON para pasar entre nuestra Vista y el Controlador.

Gran parte de la validación que hago es validar datos a medida que los usuarios ingresan. Por ejemplo, utilizo el keypressevento para evitar letras en un cuadro de texto, establecer un número máximo de caracteres y que un número esté dentro de un rango.

Supongo que la mejor pregunta sería: ¿Hay algún beneficio al hacer la validación del lado del servidor sobre el lado del cliente?

Awesome responde a todos. El sitio web que tenemos está protegido con contraseña y para una pequeña base de usuarios (<50). Si no están ejecutando JavaScript, enviaremos ninjas. Pero si estuviéramos diseñando un sitio para todos, estaría de acuerdo en hacer la validación en ambos lados.

Como otros han dicho, debes hacer ambas cosas. Este es el por qué:

Lado del cliente

Desea validar la entrada en el lado del cliente primero porque puede dar una mejor retroalimentación al usuario promedio . Por ejemplo, si ingresan una dirección de correo electrónico no válida y se mueven al siguiente campo, puede mostrar un mensaje de error de inmediato. De esa forma, el usuario puede corregir cada campo antes de enviar el formulario.

Si solo valida en el servidor, tienen que enviar el formulario, recibir un mensaje de error e intentar localizar el problema.

(Este problema puede aliviarse haciendo que el servidor vuelva a procesar el formulario con la entrada original del usuario completada, pero la validación del lado del cliente es aún más rápida).

Lado del servidor

Desea validar en el lado del servidor porque puede proteger contra el usuario malintencionado , que puede omitir fácilmente su JavaScript y enviar información peligrosa al servidor.

Es muy peligroso confiar en tu interfaz de usuario. No solo pueden abusar de su interfaz de usuario, sino que pueden no estar utilizando su interfaz de usuario en absoluto, o incluso un navegador . ¿Qué sucede si el usuario edita manualmente la URL, o ejecuta su propio Javascript, o ajusta sus solicitudes HTTP con otra herramienta? ¿Qué sucede si envían solicitudes HTTP personalizadas desde curlo desde un script, por ejemplo?

( Esto no es teórico; por ejemplo, trabajé en un motor de búsqueda de viajes que volvió a enviar la búsqueda del usuario a muchas aerolíneas asociadas, compañías de autobuses, etc., enviando POSTsolicitudes como si el usuario hubiera llenado el formulario de búsqueda de cada compañía, luego reunido y ordenado todos los resultados. El formulario JS de esas compañías nunca se ejecutó, y fue crucial para nosotros que proporcionaran mensajes de error en el HTML devuelto. Por supuesto, una API hubiera sido agradable, pero esto era lo que teníamos que hacer ) .

No permitir eso no solo es ingenuo desde el punto de vista de la seguridad, sino también no estándar: se debe permitir que un cliente envíe HTTP por cualquier medio que desee, y usted debe responder correctamente. Eso incluye validación.

La validación del lado del servidor también es importante para la compatibilidad : no todos los usuarios, incluso si están usando un navegador, tendrán habilitado JavaScript.

Anexo - Diciembre de 2016

Hay algunas validaciones que ni siquiera se pueden hacer correctamente en el código de aplicación del lado del servidor, y son completamente imposibles en el código del lado del cliente , porque dependen del estado actual de la base de datos. Por ejemplo, "nadie más ha registrado ese nombre de usuario", o "la publicación de blog que está comentando aún existe", o "ninguna reserva existente se superpone a las fechas que solicitó", o "el saldo de su cuenta todavía tiene suficiente para cubrir esa compra ". Solo la base de datos puede validar de manera confiable los datos que dependen de datos relacionados. Los desarrolladores regularmente arruinan esto , pero PostgreSQL proporciona algunas buenas soluciones .

Sí, la validación del lado del cliente puede omitirse totalmente, siempre. Debe hacer ambas cosas, el lado del cliente para proporcionar una mejor experiencia de usuario, y el lado del servidor para asegurarse de que la entrada que recibe esté realmente validada y no solo supuestamente validada por el cliente.

Solo voy a repetirlo, porque es bastante importante:

Validar siempre en el servidor

y agregue JavaScript para la capacidad de respuesta del usuario.

El beneficio de hacer la validación del lado del servidor sobre la validación del lado del cliente es que la validación del lado del cliente se puede omitir / manipular:

• El usuario final podría tener JavaScript desactivado
• Los datos podrían ser enviados directamente a su servidor por alguien que ni siquiera está utilizando su sitio, con una aplicación personalizada diseñada para hacerlo.
• Un error de Javascript en su página (causado por cualquier cantidad de cosas) podría ocasionar que se ejecute parte de su validación, pero no toda.

En resumen: siempre, siempre valide el lado del servidor y luego considere la validación del lado del cliente como un "extra" adicional para mejorar la experiencia del usuario final.

Siempre debe validar en el servidor.

También tener validación en el cliente es bueno para los usuarios, pero es completamente inseguro.

Bueno, todavía encuentro espacio para responder.

Además de las respuestas de Rob y Nathan, agregaría que tener validaciones del lado del cliente es importante. Cuando aplique validaciones en sus formularios web, debe seguir estas pautas:

Lado del cliente

1. Debe usar validaciones del lado del cliente para filtrar solicitudes genuinas provenientes de usuarios genuinos en su sitio web.
2. La validación del lado del cliente debe usarse para reducir los errores que pueden ocurrir durante el procesamiento del lado del servidor.
3. La validación del lado del cliente debe usarse para minimizar los viajes de ida y vuelta del lado del servidor para que pueda ahorrar ancho de banda y las solicitudes por usuario.

Lado del servidor

1. NO DEBE asumir que la validación realizada con éxito en el lado del cliente es 100% perfecta. No importa, incluso si sirve a menos de 50 usuarios. Nunca se sabe cuál de sus usuarios / empleados se convierte en un "malvado" y realiza alguna actividad dañina sabiendo que no tiene las validaciones adecuadas.
2. Incluso si es perfecto en términos de validación de dirección de correo electrónico, números de teléfono o verificación de algunas entradas válidas, puede contener datos muy dañinos. Que debe filtrarse en el lado del servidor sin importar si es correcto o incorrecto.
3. Si se omite la validación del lado del cliente, sus validaciones del lado del servidor vienen a rescatarlo de cualquier daño potencial al procesamiento del lado del servidor. En los últimos tiempos, ya hemos escuchado muchas historias de inyecciones SQL y otro tipo de técnicas que podrían aplicarse para obtener algunos beneficios malvados.

Ambos tipos de validaciones juegan papeles importantes en su ámbito respectivo, pero el más fuerte es el lado del servidor. Si recibe 10k usuarios en un solo punto de tiempo, definitivamente terminará filtrando la cantidad de solicitudes que llegan a su servidor web. Si descubre que hubo un solo error, como una dirección de correo electrónico no válida, volverá a publicar el formulario y le pedirá a su usuario que lo corrija, lo que definitivamente consumirá los recursos y el ancho de banda de su servidor. Así que mejor aplica la validación de JavaScript. Si JavaScript está deshabilitado, la validación del lado del servidor vendrá a rescatarlo y apuesto a que solo unos pocos usuarios podrían haberlo deshabilitado accidentalmente ya que el 99.99% de los sitios web usan JavaScript y ya está habilitado de forma predeterminada en todos los navegadores modernos.

Puede realizar la validación del lado del servidor y enviar un objeto JSON con los resultados de validación para cada campo, manteniendo el Javascript del cliente al mínimo (solo mostrando resultados) y aún teniendo una experiencia fácil de usar sin tener que repetirlo tanto en el cliente como en el servidor.

El lado del cliente debe usar una validación básica a través de tipos de entrada HTML5 y atributos de patrón, ya que estos solo se usan para mejoras progresivas para una mejor experiencia del usuario (incluso si no son compatibles con <IE9 y safari, pero no confiamos en ellos). Pero la validación principal debería ocurrir en el lado del servidor.

Sugeriré implementar la validación tanto del cliente como del servidor, mantiene el proyecto más seguro ... si tengo que elegir uno, iré con la validación del lado del servidor.

Puede encontrar información relevante aquí https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

JavaScript se puede modificar en tiempo de ejecución.

Sugiero un patrón para crear una estructura de validación en el servidor y compartir esto con el cliente.

Necesitará una lógica de validación separada en ambos extremos, por ejemplo:

"required"atributos en inputsel lado del cliente

field.length > 0 lado del servidor.

Pero el uso de la misma especificación de validación eliminará cierta redundancia (y errores) de la validación de duplicación en ambos extremos.

La validación de datos del lado del cliente puede ser útil para una mejor experiencia de usuario: por ejemplo, si un usuario que escribe incorrectamente su dirección de correo electrónico, no debería esperar hasta que un servidor remoto procese su solicitud para conocer el error tipográfico que hizo.

Sin embargo, como un atacante puede pasar por alto la validación del lado del cliente (y puede que incluso no use el navegador), se requiere la validación del lado del servidor, y debe ser la puerta de entrada real para proteger su backend de los usuarios nefastos.

Encontré un enlace interesante que hace una distinción entre errores burdos, sistemáticos y aleatorios.

Client-Side validationse adapta perfectamente para prevenir errores graves y aleatorios. Típicamente una longitud máxima para textura y entrada. No imite la regla de validación del lado del servidor; proporcione su propia regla general de validación de la regla general (por ejemplo, 200 caracteres en el lado del cliente; nen el lado del servidor dictado por una regla comercial sólida).

Server-side validationse adapta perfectamente para prevenir errores sistemáticos; hará cumplir las reglas comerciales.

En un proyecto en el que estoy involucrado, la validación se realiza en el servidor a través de solicitudes ajax. En el cliente muestro mensajes de error en consecuencia.

Lectura adicional: errores brutos, sistemáticos y aleatorios:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO

Si está realizando una validación ligera, es mejor hacerlo en el cliente. Ahorrará el tráfico de red que ayudará a que su servidor funcione mejor. Si se trata de una validación complicada que implica extraer datos de una base de datos o algo así, como contraseñas, lo mejor es hacerlo en el servidor donde los datos se pueden verificar de forma segura.