8 added 624 characters in body
source | link

Client side validation is also useful for client side applications (when it's not requesting/posting to a server). For example if you had the form given above and then displayed the contents of emailAddress in a <div> on the page by reading it with JavaScript/jquery. If the user entered something such as <script>alert('hello!');</script> and there was no validation, it would produce an alert when the JavaScript attempted to write the value in the field to the <div>. Nothing is being posted to the server in this case - it all happens client side - so again client side validation is useful in this type of scenario. However the same rationale applies in that a user can still disable the validation. The impact here is lower because if they did run the above code it would only happen on their local machine, not to other users of the application. For example:

enter image description here

Using the following code (without any validation):

<form method="post" action="#">
    <input type="text" name="emailAddress" id="emailAddress" size="100">
    <button type="submit">Submit form</button>
</form>

<div id="test"></div>

And jquery to write the form contents to a <div> with the ID test:

$(document).ready(function() {
    $("button").click(function(e) {
        e.preventDefault();

        $("#test").html($("#emailAddress").val());
    });
});

Client side validation is also useful for client side applications (when it's not requesting/posting to a server). For example if you had the form given above and then displayed the contents of emailAddress in a <div> on the page by reading it with JavaScript/jquery. If the user entered something such as <script>alert('hello!');</script> and there was no validation, it would produce an alert when the JavaScript attempted to write the value in the field to the <div>. Nothing is being posted to the server in this case - it all happens client side - so again client side validation is useful in this type of scenario. However the same rationale applies in that a user can still disable the validation. The impact here is lower because if they did run the above code it would only happen on their local machine, not to other users of the application.

Client side validation is also useful for client side applications (when it's not requesting/posting to a server). For example if you had the form given above and then displayed the contents of emailAddress in a <div> on the page by reading it with JavaScript/jquery. If the user entered something such as <script>alert('hello!');</script> and there was no validation, it would produce an alert when the JavaScript attempted to write the value in the field to the <div>. Nothing is being posted to the server in this case - it all happens client side - so again client side validation is useful in this type of scenario. However the same rationale applies in that a user can still disable the validation. The impact here is lower because if they did run the above code it would only happen on their local machine, not to other users of the application. For example:

enter image description here

Using the following code (without any validation):

<form method="post" action="#">
    <input type="text" name="emailAddress" id="emailAddress" size="100">
    <button type="submit">Submit form</button>
</form>

<div id="test"></div>

And jquery to write the form contents to a <div> with the ID test:

$(document).ready(function() {
    $("button").click(function(e) {
        e.preventDefault();

        $("#test").html($("#emailAddress").val());
    });
});
7 added 827 characters in body
source | link

Client side validation is also useful for client side applications (when it's not requesting/posting to a server). For example if you had the form given above and then displayed the contents of emailAddress in a <div> on the page by reading it with JavaScript/jquery. If the user entered something such as <script>alert('hello!');</script> and there was no validation, it would produce an alert when the JavaScript attempted to write the value in the field to the <div>. Nothing is being posted to the server in this case - it all happens client side - so again client side validation is useful in this type of scenario. However the same rationale applies in that a user can still disable the validation. The impact here is lower because if they did run the above code it would only happen on their local machine, not to other users of the application.

Client side validation is also useful for client side applications (when it's not requesting/posting to a server). For example if you had the form given above and then displayed the contents of emailAddress in a <div> on the page by reading it with JavaScript/jquery. If the user entered something such as <script>alert('hello!');</script> and there was no validation, it would produce an alert when the JavaScript attempted to write the value in the field to the <div>. Nothing is being posted to the server in this case - it all happens client side - so again client side validation is useful in this type of scenario. However the same rationale applies in that a user can still disable the validation. The impact here is lower because if they did run the above code it would only happen on their local machine, not to other users of the application.

6 edited body
source | link

So I can submit this to the server. The text string "andy" is obviously not a valid email address. But since we have no validation server side validation (yet) it'll quite happily be posted to the server and then if the PHP code used $_POST['emailAddress'] it would have "andy" as its data.

Although this is a non-friendly error handling method, it will stop script execution if the user submits "andy" instead of a valid email address. The application will therefore never use "andy" as a variable it was expecting an email address to be in. Since the end user cannot manipulate the PHP code above, there's less chance they can bypass the validation. This is server side validation - it can't be (easily) changed by an end-user because it's not within their control to change it.

Why bother with client side validation at all then? Client side validation is useful for "nice looking" user interface enhancements, or for example error messages/disabling form fields. For example, it's arguably a good UI feature to have that message on the first screenshot in case the user mis-types an email address. The form won't even submit under the first set of conditions, thus reducing un-necessary data being sent to the server. But ultimately, anything done client-side can be changed by the end-user. So it's in no way secure and you should never think of "client side validation" when it comes to security practices. AnythingAny client side validation is largely for User Interface enhancements only.

So I can submit this to the server. The text string "andy" is obviously not a valid email address. But since we have no validation server side (yet) it'll quite happily be posted to the server and then if the PHP code used $_POST['emailAddress'] it would have "andy" as its data.

Although this is a non-friendly error handling method, it will stop script execution if the user submits "andy" instead of a valid email address. The application will therefore never use "andy" as a variable it was expecting an email address to be in. Since the end user cannot manipulate the PHP code above, there's less chance they can bypass the validation. This is server side validation - it can't be (easily) changed by an end-user.

Why bother with client side validation at all then? Client side validation is useful for "nice looking" user interface enhancements, or for example error messages/disabling form fields. For example, it's arguably a good UI feature to have that message on the first screenshot in case the user mis-types an email address. The form won't even submit under the first set of conditions, thus reducing un-necessary data being sent to the server. But ultimately, anything done client-side can be changed by the end-user. So it's in no way secure and you should never think of "client side validation" when it comes to security practices. Anything client side is largely for User Interface enhancements only.

So I can submit this to the server. The text string "andy" is obviously not a valid email address. But since we have no server side validation (yet) it'll quite happily be posted to the server and then if the PHP code used $_POST['emailAddress'] it would have "andy" as its data.

Although this is a non-friendly error handling method, it will stop script execution if the user submits "andy" instead of a valid email address. The application will therefore never use "andy" as a variable it was expecting an email address to be in. Since the end user cannot manipulate the PHP code above, there's less chance they can bypass the validation. This is server side validation - it can't be (easily) changed by an end-user because it's not within their control to change it.

Why bother with client side validation at all then? Client side validation is useful for "nice looking" user interface enhancements, or for example error messages/disabling form fields. For example, it's arguably a good UI feature to have that message on the first screenshot in case the user mis-types an email address. The form won't even submit under the first set of conditions, thus reducing un-necessary data being sent to the server. But ultimately, anything done client-side can be changed by the end-user. So it's in no way secure and you should never think of "client side validation" when it comes to security practices. Any client side validation is largely for User Interface enhancements only.

5 added 17 characters in body
source | link
4 added 17 characters in body
source | link
3 added 17 characters in body
source | link
2 added 17 characters in body
source | link
1
source | link