validacion - validar nombre javascript
¿Por qué necesitamos una validación tanto del lado del cliente como del lado del servidor? (5)
El argumento para usar tanto la validación del lado del cliente (JavaScript) como la del lado del servidor con un validador es la siguiente: si el navegador del cliente no admite JavaScript, entonces el usuario no puede usar la validación del lado del cliente.
Mi pregunta es ¿qué tan bueno es este argumento en la práctica? En teoría, tiene sentido, pero en la práctica, si JavaScript está desactivado en el navegador, entonces la mayoría de las características del sitio web ni siquiera funcionarán. El usuario probablemente ni siquiera puede cargar la página sin JavaScript, y mucho menos enviar un formulario.
La validación del lado del cliente es una solución para formularios altamente interactivos con validación de campo sobre la marcha, pero no evitará que un usuario malintencionado inyecte y publique datos formateados no válidos en el servidor. Es importante que su script del lado del servidor valide todo lo que está haciendo el usuario, de lo contrario expondrá su sitio a ataques de inyección SQL, ataques XSS, usuarios haciendo cosas que no deberían, etc.
La validación del lado del cliente simplemente evita que el cliente vaya "pero yo llené todo esto y no me dijo nada". En realidad , no es obligatorio, y en realidad, la validación del lado del cliente es algo muy nuevo (léase: 5 años o menos). En la práctica, lo único que hace es evitar que su cliente (con JS habilitado) sepa si el formulario está bien antes de volver a cargar una página. Si AJAX está en el juego, es diferente: le permite ahorrar ancho de banda y también proporcionar retroalimentación al usuario antes de enviarlo. Finalmente, si está creando aplicaciones de intercambio punto a punto para el cliente (juegos de pensar), querrá la validación del lado del cliente para evitar que los clientes hagan trampa.
La validación del lado del servidor también es crucial debido al hecho de que la validación del lado del cliente se puede eludir por completo desactivando JavaScript. En cierto modo, la validación basada en JS es una conveniencia y una mejora estética / cosmética y no se debe confiar en ella. Además, es trivial editar el origen de una página localmente para deshabilitar o eludir incluso la más compleja validación de JS.
¿Qué podría hacer un usuario si no valida el lado del servidor? Cualquier cosa, dependiendo de cómo uses sus datos. Podrías permitirles a los usuarios descartar bases de datos completas (o peor, filtrarlas), modificar lo que quieran (o peor, leer todo lo que quieran. Los defectos de cruce de directorios son puntos de entrada extremadamente comunes para personas traviesas) y elevar sus privilegios a voluntad. ¿Quieres correr este riesgo? No validar la entrada del usuario es como confiar en las personas y no instalar bloqueos en su casa.
Si un usuario ha inhabilitado javascript es un problema de sí mismo y decidió desactivar el javascript por una razón ... Para eso, cuando crea un sitio web, debe tener siempre en cuenta que su sitio web debe ser válido para usuarios con y sin javascript La validación de ambos lados es necesaria por una serie de razones, algunas de ellas son:
- El usuario ha desactivado javascript
- Un usuario malvado a propósito ha eliminado el javascript para explotar el sistema
- Con la validación de JavaScript se reduce el tráfico de datos entre el sitio web y el cliente.
- Y, por supuesto, con la validación del servidor, asegúrese de una vez que todos los datos sean correctos
Es posible tener un sitio web que use ambas tecnologías, javascript y "antiguas", para que sea válida para todos los usuarios y para todos los navegadores.
Proteja siempre sus entradas en el servidor . No siempre se trata de que los usuarios tengan JavaScript desactivado, sino que también puedan romper el servidor.
Por ejemplo, si un sitio tiene una verificación de longitud máxima de JavaScript en una <input> , un usuario puede inhabilitar esa verificación, enviando de ese modo más datos de los que su servidor y / o base de datos esperan. Esto podría sobrecargar el servidor por una POST grande que ocupa un hilo de servidor durante mucho tiempo, podría exponer una debilidad en la base de datos, por ejemplo, al violar una restricción de la base de datos que podría exponer detalles sobre cualquier información de persistencia. Peor aún, si no hay restricciones, un usuario podría realizar ataques de inyección.
Otro ejemplo es alguien que usa una herramienta HTTP externa para enviar solicitudes a su servidor, evitando por completo cualquier JavaScript. Uso el Cliente REST Avanzado para Chrome todo el tiempo en desarrollo para probar las API JSON.
La validación del lado del cliente a través de JavaScript es solo una forma de proporcionar una retroalimentación más rápida a una persona que utiliza el sitio de cualquier información sobre su interacción con el sitio. En la comunicación tradicional cliente-servidor, no debería ser la única validación por los motivos descritos anteriormente.
La validación siempre debe realizarse en el lado del servidor; nunca se puede confiar en la validación del lado del cliente.
La validación del lado del cliente siempre es en el sentido de proporcionar una mejor Experiencia del Usuario (UX), por lo que el usuario no tiene que enviar y volver a cargar una página simplemente porque un valor en un formulario no es válido: hace que las cosas sean más dinámicas.
Como ni siquiera necesita un navegador para realizar solicitudes, independientemente de que su sitio web dependa de que JS funcione correctamente, necesitará una validación del lado del servidor y desinfectará todos los comentarios de los usuarios en caso de que no desee que se abran sus bases de datos.
Ahora depende de usted si desea proporcionar una IU con sugerencias dinámicas de validación del lado del cliente o no.