Una explicación con código y capturas de pantalla
Las respuestas dadas son geniales. Pero quería ilustrar esto con algunos códigos / capturas de pantalla.
La conclusión es que cualquier cosa del lado del cliente puede ser manipulada (deshabilitada / eliminada por completo / anulada o modificada) por el usuario final. Por lo tanto, cualquier tipo de "validación del lado del cliente" es totalmente inútil desde una perspectiva de seguridad. Siempre debes validar las cosas del lado del servidor.
Supongamos que tiene un formulario HTML como este:
<form method="post" action="index.php">
<input type="email" name="emailAddress" required>
<button type="submit">Submit form</button>
</form>
Esto solicita una dirección de correo electrónico ( type="email" ) y dice que es un campo obligatorio (atributo required ).
Si intento enviar algo que está vacío o no es una dirección de correo electrónico, se producirá un error, por ejemplo.
¿Porquéestoesinútildesdeunaperspectivadeseguridad?TodoloqueelusuariotienequehaceresmanipularelHTML.Puedenhacerloguardandounacopiadelapáginaweb,editándolayluegovolviéndolaaabrir.Opuedenusarlasherramientasdeldesarrolladorensunavegadorparaeditarelmarcado.Puedenhacerloporqueeselcódigodelladodelclienteyestábajosucontrol.
Digamosquecambioelformatodelformularioaesto:
<formmethod="post" action="index.php">
<input type="text" name="emailAddress">
<button type="submit">Submit form</button>
</form>
Ahora estoy diciendo que el campo emailAddress es de tipo text (es decir, no es email ) y no es un campo obligatorio (se eliminó el atributo required ).
Así que puedo enviar esto al servidor. La cadena de texto "andy" obviamente no es una dirección de correo electrónico válida. Pero dado que no tenemos una validación del lado del servidor (todavía), se publicará en el servidor y luego, si el código PHP utiliza $_POST['emailAddress'] , tendría "andy" como datos.
Tambiénpodríaenviarelformulariosindatos,encuyocasolaaplicación,sinningunavalidacióndelladodelservidor,tendríaunacadenavacíaenlavariable$_POST['emailAddress'].
Estosolofueposibleporqueyo,comousuariofinal,podíamanipularelcódigodelladodelcliente.
¿Porquéesseguralavalidacióndelladodelservidor?Elusuariofinalnopuedemanipularelcódigodelladodelservidor(amenosqueelservidorhayasidocomprometido,peroeseesunproblemaaparteynoesalgotanfácilcomomanipularHTMLparalapersonapromedio).
Entonces,enPHP,podríahacerunacomprobacióncomoesta:
if(!filter_var($_POST['emailAddress'],FILTER_VALIDATE_EMAIL)){die('Invalidemailaddress');}
Aunqueesteesunmétododemanejodeerroresnoamigable,detendrálaejecucióndelscriptsielusuarioenvía"andy" en lugar de una dirección de correo electrónico válida. Por lo tanto, la aplicación nunca utilizará "andy" como una variable en la que se esperaba una dirección de correo electrónico. Dado que el usuario final no puede manipular el código PHP anterior, hay menos posibilidades de que puedan omitir la validación. Esta es la validación del lado del servidor, no puede ser (fácilmente) cambiada por un usuario final porque no está bajo su control cambiarla.
¿Por qué molestarse en la validación del lado del cliente entonces? La validación del lado del cliente es útil para las mejoras de la interfaz de usuario de "buen aspecto", o por ejemplo, mensajes de error / deshabilitación de campos de formulario. Por ejemplo, podría decirse que es una buena función de IU para tener ese mensaje en la primera captura de pantalla en caso de que el usuario escriba incorrectamente una dirección de correo electrónico. El formulario ni siquiera se enviará en el primer conjunto de condiciones, lo que reducirá los datos innecesarios que se envían al servidor. Pero en última instancia, cualquier cosa hecha por el cliente puede ser cambiada por el usuario final. Por lo tanto, no es seguro de ninguna manera y nunca se debe pensar en la "validación del lado del cliente" cuando se trata de prácticas de seguridad. Cualquier validación del lado del cliente es en gran parte solo para mejoras de la interfaz de usuario.
La validación del lado del cliente también es útil para las aplicaciones del lado del cliente (cuando no está solicitando / publicando en un servidor). Por ejemplo, si tenía el formulario indicado anteriormente y luego mostró los contenidos de emailAddress en un <div> en la página, leyéndolo con JavaScript / jquery. Si el usuario ingresó algo como <script>alert('hello!');</script> y no hubo validación, produciría una alerta cuando el JavaScript intentara escribir el valor en el campo en el <div> . No se está publicando nada en el servidor en este caso, todo sucede en el lado del cliente, por lo que, de nuevo, la validación del lado del cliente es útil en este tipo de escenario. Sin embargo, el mismo razonamiento se aplica en que un usuario todavía puede deshabilitar la validación. El impacto aquí es menor porque si ejecutaran el código anterior, solo ocurriría en su máquina local, no en otros usuarios de la aplicación. Por ejemplo:
Utilizandoelsiguientecódigo(sinningunavalidación):
<formmethod="post" action="#">
<input type="text" name="emailAddress" id="emailAddress" size="100">
<button type="submit">Submit form</button>
</form>
<div id="test"></div>
Y jquery para escribir el contenido del formulario en un <div> con el ID test :
$(document).ready(function() {
$("button").click(function(e) {
e.preventDefault();
$("#test").html($("#emailAddress").val());
});
});