Table of Content
Understanding the working of a web form and the different parts involved.
<form> <fieldset> <legend>Log In</legend> <label>Username: <input type="text"></label> <label>Password: <input type="password"></label> <input type="submit" value="Submit"> </fieldset> </form>
Your visitor loads the form page in the web browser
The browser sends a request to the web server. The web server returns the HTML page that contains the form.
The HTML page returned can be:
– an HTML file on the server.
– an HTML page generated by a script running on the web server
Your visitor fills the form
The form submission data is sent to the web server
Once the visitor has submitted the form, the form data is sent to the web server. In the form, the author of the form has to mention an ‘action’ URL that tells the browser where to send the form submission data. The ‘action’ usually points to the URL of a script that knows what to do with the data.
A web server processes the request
The web server passes the form submission data to the form processor script ( mentioned by the ‘action’). The form processor script is written in languages like PHP, ASP, or Perl. The form processor script can send the form data by email, save the data to a database or file.
The response is sent back to the browser
The form processor script sends a response indicating the success or failure of the form processing operations back to the server. The response could be to redirect to another web page.
As you can see, sending form data is easy, but securing an application can be tricky. Just remember that a front-end developer is not the one who should define the security model of the data. Yes, as we’ll see, it’s possible to perform client-side data validation, but the server can’t trust this validation because it has no way to know what really happens on the client side.