Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

JavaScript

Posted by Christopher Neville
Christopher Neville
191 Points

Javascript/CSS - Code bypassed by user

Hello,

I'm currently developing a web app using PHP and JS. In some cases, I want to disable a submit button using JS (jQuery), depending on the user's selection from a select box. I am able to make it work, however, I notice that using Chrome's Inspect Element (source), as a user I can delete the disabled property from the button and then click it successfully - therefore bypassing my restriction.

In a real world environment, how can I ensure that users cannot modify the code "on the fly" in order to bypass my coded restrictions?

Any help would be greatly appreciated.

Chris

2 Answers

Marcus Parsons
Marcus Parsons
15,719 Points

Hey Christopher,

The reason why a user is able to easily bypass most JavaScript is because the code often times lives in the global namespace. When you go into the console of Chrome or Firefox (and I think Safari), you can access any resources created by JavaScript if they're in the global namespace. I'm not sure if you're using the "disabled" property on the submit button, but I would not use that. I would use the submit event handler to not allow a user to submit the form data if it is not valid.

To circumvent this behavior, wrap all of your JavaScript code in an anonymous self-invoking function expression like this (this is but one way to do it):

!function() {
//your JS here
}();

Since this is an anonymous function that is self invoked (and has nothing passed into it), any variables/functions/etc. will not be available to the global window and by proxy, the console. JavaScript operates under function scope so variables/functions/etc. created under a function are considered local to the function and are destroyed once the function executes. Any variables/functions/etc. created outside of this function (not within their own functions) are accessible by this function. Also, be sure to use the var keyword for any variables created within this function so that they are localized to the function. If you leave off the var keyword when initializing them, they will be hoisted into the global namespace and be accessible by the user.

I did the exact same thing I mentioned above with preventing form submission with the JavaScript validation I use on my contact form. You can check out my contact form here: http://www.marcusparsons.com/contactme.php. And just go into the source of the page (Ctrl + U), scroll down to the bottom and look at "contactme.js". You'll see that my code is wrapped in that function and that I set some variables for validity. Those variables cannot be manipulated by the user in the console.

Edit: I'm sure you're aware, but even client side validation is not foolproof. JavaScript can still be disabled and event handlers be detached despite the the functions being secluded from the global namespace. Server side validation is still a must when dealing with processing any kind of data from a user.

Marcus Parsons
Marcus Parsons
15,719 Points

One thing to keep in mind when cutting your code off from the global namespace is that you cannot use any functions declared in the anonymous function with attributes in the HTML document. You need to add the event listeners inside the function instead of in attributes in the HTML. For example,

Don't do this (it won't work):

<button onclick="doAFunkyDance();">Do A Funky Dance!</button>

!function() {
function doAFunkyDance() {
//DO A FUNKY DANCE ^_^
alert("I'm doing a funky dance! ^_^");
}
}();

Do do something like this (will allow you to do a funky dance!):

<button id="doAFunkyDanceButton">Do A Funky Dance!</button>

!function() {
function doAFunkyDance() {
//DO A FUNKY DANCE ^_^
alert("I'm doing a funky dance! ^_^");
}

document.getElementById('doAFunkyDanceButton').addEventListener('click', doAFunkyDance, false);
}();
Christopher Neville
Christopher Neville
191 Points

Thanks Marcus for your detailed response! I really appreciate your feedback.

Marcus Parsons
Marcus Parsons
15,719 Points

You're welcome, Chris!

Jason Anello
PLUS
Jason Anello
Courses Plus Student 94,610 Points
Jason Anello
Jason Anello
Courses Plus Student 94,610 Points

Hi Christopher,

In a real world environment, how can I ensure that users cannot modify the code "on the fly" in order to bypass my coded restrictions?

Unfortunately, you can't ensure this.

Javascript can be manipulated and it can even be turned off. You have to consider the possibility that your code will never even be executed.

As you've already discovered, you can enable the submit button by removing the disabled property. Presumably your current solution is running some code in response to changing input controls and then enabling the button when everything checks out.

Alternatively, you might attach a submit event handler to your form to intercept form submission like this:

$( "form" ).submit(function( event ) {
  // if something's wrong prevent the form submission with event.preventDefault();
});

However, I can run the following code in the console to detach that event handler:

$("form").off('submit');

Now I can submit the form without filling anything out.

Client side form validation should only be used to enhance the user experience and not for security. i.e. It's for legitimate users and not malicious users.

Client side validation can be used to give immediate feedback to the user that they've done something wrong. In your case, they haven't selected the right options yet. This saves them from a round trip to the server and a full page reload only to find out they did something wrong.

Security is something that should be handled on the server side. It's your last line of defense. Whatever you're checking on the client needs to be checked again on the server because of the tampering that can happen. In your case, you'd have to make sure the option in the select box that was chosen was what you were expecting.

As an example, let's say your form is allowing users to create an account and you want to validate that usernames are at least 8 characters. If the user bypasses this code then they can submit the form with less than 8 characters for the username. You can't just blindly create the user account when it gets to your form submission script. You have to check again on the server that the username is at least 8 characters. If you discover it's not then you know the form was tampered with or possibly a user has js disabled by choice. Then you can reload the page with an appropriate error message.

Marcus Parsons
Marcus Parsons
15,719 Points

Client side validation is just the front line of defense and interactivity. Server side validation should always accompany client side validation.

Marcus Parsons
Marcus Parsons
15,719 Points

And now that I'm back at my computer, I can formulate a proper response. No, you can't fully ensure that client side validation works, but if you did as I do (and as module programming is done), you separate your validation so that it doesn't operate in the global namespace, it's harder to bypass the code. The average user doesn't know that you can detach event handlers. But server side validation is a must regardless of whether you use client side validation or not.

Christopher Neville
Christopher Neville
191 Points

Thanks Jason for your detailed response! I really appreciate your feedback.