Confessions of a Web Developer - Beating Web Validation

I have a confession to make...

One balmy summer evening recently, whilst booking a cinema ticket on-line, I used my ninja web development skills to book a seat I wasn't really allowed to.

This was a little naughty, but there were of course, mitigating circumstances. We had already booked two tickets previously, and wanted to book another seat. Luckily, next to the seats we had booked were two free seats. Great! We selected the free square from the grid of cinema seats in front of us. On clicking the 'Next' button we were confronted with a dialog telling us that we were not allowed our seat, because it would leave a single, unoccupied seat. Terrible!

That was irritating, particularly because were happy to have been able to bag a seat next to us, only to have it taken away from us after that fact.

As the sense on injustice kicked in, a thought occurred to me, could I simply remove the validation?

Yes, I could! A press of F12 to bring up chrome dev. tools, a little searching through the JavaScript to find the validation code, a little hacking....and a few minutes later we had the ticket!

This was far easier that it should have been, and there are some simple techniques that could have been employed to make what I did much harder.

Minifying the code

The JavaScript code in use was very easy to read and change. Once I had opened Chrome developer tools I was able to search for the error message displayed in the dialog. I was immediately presented with the area of code handling the validation for the seats, contained in a function called 'SeatValdation'. The code looked a little like this (code has been pixelated to protect the innocent):


The code was nicely structured and readable. This is of course essential for development. It's easy to adapt and maintain. The downside of this, is that it was also very easy for me to adapt with my malevolent intentions.

Minfying the code is a technique that takes formatted, readable code, and compresses it to within an inch of it's life. The main benefit of doing this, is that physical size of the code is much reduced. This yields a much smaller payload of data that needs to be downloaded in order to render pages containing the code, meaning pages will load faster. This is a very good thing. Especially given that it's widely believed Google use a page load time metric to help decide on search rankings of pages.

Another great benefit of doing this, is that it makes the code far less readable. Every word in code (with the exception of anything presented to the user), is substitued with a much shorter label.

For example (taken from

function validateForm() {
    var x = document.forms["myForm"]["fname"].value;
    if (x == null || x == "") {
        alert("First name must be filled out");
        return false;


function validateForm(){var e=document.forms["myForm"]["email"].value;var t=e.indexOf("@");var n=e.lastIndexOf(".");if(t<1||n<t+2||n+2>=e.length){alert("Not a valid e-mail address");return false}}

( used to minify)

Even for the uninitiated, with no structure, you can see that this is much harder to follow. This is by no means bullet-proof, you can still follow the code, and the error message does not change, providing the perfect anchor to find the area of code. It does, however, make it much more difficult. Particularly in real-world situations, where there is much more surrounding code. It would take longer to understand and adapt the code.

It may just be enough to put off a cheeky developer from attempting to alter the code, and would provide all of the associated benefits.

N.B. Minifying the code is usually performed as an automated step when preparing a release. Development is conducted against the readable, structured form of the same code.

Server side validation

To make it impossible for this type of hack to be carried, the validation could be performed both on the browser AND the server that it is communicating with. The major difference with server-side validation, is that there is no way I, a cheeky web developer, can make changes to the servers code.

If, in this situation, the seats were also validated on the server side, this is what would have happened:

  • I would have attempted to hack the code running in my browser as before
  • Upon clicking next, the same dialog would not be displayed
  • The information I entered on the page would be sent to the server
  • The server would then validate the data entered
  • It would then identify that a single seat has been left empty
  • The server would then respond with information detailing the error
  • The browser would then display the validation to me, and I would not be able to continue with the booking process.

A key difference with server side validation is that the feedback cycle between the user and the page is longer. This is because information has to be sent from the users browser, across the internet to the sites server, and back again. It's often desirable to provide both client side and server side validation in these cases.

User experience

Why was I so keen to circumvent this validation rule? After all, it's not always so easy. I think a large factor is because I was annoyed. The page let me select the seat I wanted, I was happy. It wasn't until clicking the next button on the page that I was informed I was not allowed to do this. The web gaveth, and the web tooketh away.

Had we not be able to select the seat in the first instance, it might not have occurred to me to even try.

Wider consequences

This is a very low risk, almost banal example of hacking, but it serves to highlight the importance of client side validation. I would never try, but could it be possible to alter more sensitive code? Altering the cost of tickets presented on the page? Getting this aspect of a sites code wrong can have very dangerous consequences.

As it turned out, that empty seat was filled by the time the film had started, so I felt a little less guilty.

'X-Men: Days of Future Past!' is really good by the way :)

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.