Even with all the flaws that we will find in an Ajax based website, there are security measures that we could do to ensure security in our website.
Before we go to different security measures, let us first note one of the biggest problems in an Ajax based website and application: Source Code Availability. Some call it “Overly Granular Server API” referring to the API built from the server which provides little to nothing in terms of security.
Almost every hack that I have seen related to Ajax stems from this security flaw. In simple words, the biggest problem in Ajax is the availability of source code even to regular users.
Developers who follow this practice do this thinking that the code will eventually help regular users in browsing the website. Take for example an Ajax based shopping cart. Instead of having to go through different pages in security and setting up parameters, developers will just place everything in a single page. That exact page will hasten the process of regular user’s shopping. When this process is used, developers have achieved the purpose of the coding it that way.
However, they pay the price of showing the source code of the website. If they are hoping that no one will notice this and use it for bad intentions, they are definitely wrong. The source code is essentially the key to every hack in an Ajax based website. The easier hackers get their hands to the source code, the faster they could attack the system. A source code in an online store is a sitting duck for hackers. They could easily bypass the admin and change the security settings and even the prices so they could easily shop online without any problem – or payment.
To counter this problem, we pose two different security measures:
The first security measure is the way we build our website. We go back to the shopping cart where the price is presented to the online shopper. Hackers could easily see the source code and change the parameters. Instead of presenting the price altogether, it’s always a better practice to divide the information in every page. With that practice you should be able to set specific parameters in every page. That way, every time a new page loads, it should be able to detect changes in any part of the system. Hackers would have to change everything in your website just to hack the price and before they could do that, you already detected the attacks and prevent them.
If ever you will be forced to place the entire transaction in a single page, you should opt for a secured coding practice. Our usual practice is to place comments within the code so that other developers will easily understand the process even though you are not there to explain. Doing that in the source code means suicide when it comes to security. Instead of placing comments right in the website, build another copy of the code with the comments. Although it does not provide that much of a protection, a comment-less web program can help with the website’s security.
