validación de formulario [cerrado]

Como @Alex mencionó en el comentario, si cruza un límite de seguridad, debe ser cuidadoso y deliberado sobre el manejo de los datos y comprender cómo un atacante podría manipularlos antes de enviárselos.

Este proceso es más conocido como modelado de amenazas de aplicaciones. Comienza con la definición de los componentes de la aplicación, los flujos de datos entre los componentes, donde dichos flujos de datos cruzan los límites de seguridad y lo que esos datos pueden contener. Una vez que sepa esto, puede pensar en cómo un atacante podría abusar de los datos antes de enviarlos a través de esos límites, de modo que pueda identificar mejor cómo mitigar esas vulnerabilidades potenciales.

Piense en dónde podrían usarse los datos, ya que esto ayudará a definir su validación.

Puede salir sin validación en el momento de la entrada, sin embargo, cualquier cosa que tenga un significado especial al usar una función de sumidero debe descartarse o codificarse antes de su uso. La validación en el momento de la entrada es útil si desea permitir que su usuario pueda corregir cualquier error.

La desinfección se debe hacer lo más tarde posible. Por ejemplo, la conversión a caracteres HTML se debe hacer en la salida en lugar de en la entrada. El motivo es que si decide utilizar los datos en un contexto diferente, puede convertirlos en este punto directamente desde el valor del usuario (por ejemplo, texto sin formato, JSON, etc.).

Nunca confíes en la entrada del usuario. Valide todo antes de usarlo e intente pensar en los peligros de dejar valores inesperados enviados desde su formulario, por ejemplo, si se falsificó un determinado valor o si el valor terminará sin codificar cuando se use en un contexto con un significado especial (por ejemplo, SQL declaración).