validar validacion vacios pattern formularios formulario enviar ejemplos ejemplo con campos antes javascript security validation

validacion - JavaScript: validación del lado del cliente vs. lado del servidor



validar formulario javascript onclick (12)

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

En nuestra situación, estamos usando

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

Mucha de la validación que hago es validar los datos a medida que los usuarios ingresan. Por ejemplo, utilizo el evento de keypress para evitar letras en un cuadro de texto, establezco un número máximo de caracteres y con un número dentro de un rango.

Supongo que la mejor pregunta sería: ¿hay algún beneficio para hacer la validación del lado del servidor por el lado del cliente?

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

Bueno, aún encuentro espacio para responder.

Además de las respuestas de Rob y Nathan, agregaría que es importante tener validaciones del lado del cliente. 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 se debe usar 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 si sirve a menos de 50 usuarios. Nunca se sabe cuál de sus usuarios / empleados se convierte en un "malvado" y realizan alguna actividad dañina sabiendo que no tienen las validaciones adecuadas en su lugar.
  2. Incluso si es perfecto en términos de validar la dirección de correo electrónico, números de teléfono o verificar algunas entradas válidas, podría contener datos muy dañinos. Que necesita ser filtrado en el lado del servidor sin importar si es correcto o incorrecto.
  3. Si se anula la validación del lado del cliente, las validaciones del lado del servidor lo rescatarán de cualquier daño potencial en el procesamiento del lado del servidor. En los últimos tiempos, ya hemos escuchado muchas historias de inyecciones de SQL y otro tipo de técnicas que podrían aplicarse para obtener algunos beneficios malvados.

Ambos tipos de validaciones desempeñan papeles importantes en sus respectivos ámbitos, pero el más fuerte es el lado del servidor. Si recibe 10k de usuarios en un único punto de tiempo, definitivamente terminaría filtrando el número de solicitudes que llegan a su servidor web. Si descubres que hubo un solo error, como una dirección de correo electrónico no válida, vuelven a publicar el formulario y le piden al usuario que lo corrija, lo que definitivamente consumirá los recursos del servidor y el ancho de banda. Así que mejor aplicas la validación de JavaScript. Si javascript está deshabilitado, entonces la validación del lado del servidor vendrá a rescatar y apuesto a que solo unos pocos usuarios podrían haberlo deshabilitado accidentalmente ya que el 99.99% de los sitios web usa javascript y ya está habilitado por defecto en todos los navegadores modernos.

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

Lado del cliente

Primero, debe validar las entradas del lado del cliente porque puede proporcionar mejores comentarios al usuario medio . Por ejemplo, si ingresan una dirección de correo electrónico no válida y pasan al siguiente campo, puede mostrar un mensaje de error de inmediato. De esta forma, el usuario puede corregir cada campo antes de enviar el formulario.

Si solo valida en el servidor, debe enviar el formulario, obtener un mensaje de error e intentar buscar el problema.

(Este dolor 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 protegerse contra el usuario malintencionado , que puede eludir fácilmente su JavaScript y enviar entradas peligrosas al servidor.

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

( Esto no es teórico, por ejemplo, trabajé en un motor de búsqueda de viajes que reenvió la búsqueda del usuario a muchas aerolíneas, compañías de autobuses, etc., enviando solicitudes POST como si el usuario hubiera llenado el formulario de búsqueda de cada empresa, luego se reunieron y clasificaron todos los resultados. El 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 habría sido agradable, pero esto era lo que teníamos que hacer ) .

No permitir eso no es solo ingenuo desde el punto de vista de la seguridad, sino también no estándar: un cliente debe poder enviar 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 usan un navegador, tendrán habilitado JavaScript.

Adición - diciembre de 2016

Hay algunas validaciones que ni siquiera se pueden realizar correctamente en el código de la aplicación del lado del servidor, y son completamente imposibles en el código del lado del cliente , ya que 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 todavía 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 confiablemente datos que dependen de datos relacionados. Los desarrolladores regularmente lo estropean , pero PostgreSQL ofrece algunas buenas soluciones .

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 puede ser evitada / manipulada:

  • El usuario final podría tener javascript desactivado
  • Los datos pueden ser enviados directamente a su servidor por alguien que ni siquiera está usando 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 su validación se ejecute en algunas, pero no en todas.

En resumen: siempre valide siempre 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.

El lado del cliente debe usar una validación básica mediante tipos de entrada HTML5 y atributos de patrones, 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 ...

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

Client-Side validation adapta perfectamente para evitar errores gruesos y aleatorios. Por lo general, una longitud máxima para la textura y la entrada. No imite la regla de validación del lado del servidor; proporcione su propia regla de validación bruta, de regla general (por ejemplo, 200 caracteres en el lado del cliente; n en el lado del servidor dictada por una regla de negocios sólida).

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

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

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

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

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:

atributos "required" en las inputs del lado del cliente

field.length > 0 del lado del servidor.

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

Puede hacer 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 los resultados) y teniendo una experiencia amigable sin tener que repetir tanto en el cliente como en el servidor.

Sí, la validación del lado del cliente puede ser totalmente ignorada, siempre. Debe hacer las dos cosas, el lado del cliente para proporcionar una mejor experiencia de usuario, y el lado del servidor para asegurarse de que la entrada que obtiene sea validada y no supuestamente validada por el cliente.

Si está haciendo una validación de luz, lo mejor es hacerlo en el cliente. Salvará el tráfico de red que ayudará a que su servidor funcione mejor. Si complica la validación que implica extraer datos de una base de datos o algo así, como las contraseñas, entonces lo mejor es hacerlo en el servidor donde los datos se pueden verificar de forma segura.

Voy a repetirlo, porque es bastante importante:

Validar siempre en el servidor

y agregue JavaScript para que el usuario responda.

Siempre debe validar en el servidor.

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