Attacks to web applications is not a new threat variant.  It has been around for the longest time, probably ever since the first websites went up en masse which was during the height of the Internet Bubble.  Back then, anything and everything was registered with a .com, and even if you had a business plan that was even partially viable, you got VC funding right away. 

Back then, the primary building frameworks for all of these web applications was that of ASP.NET, and Cold Fusion (from Adobe).  There was also the standard HTML code as well that you could use.

But now, the advancements in web application has changed dramatically, where many software development teams now make use of such source code languages as PHP, Ruby on Rails, and the big one, Python.  But with the pandemic of COVID19, attacks to these web applications have proliferated to the greatest levels ever yet. 

This finding has been further substantiated by the recent study that was conducted by Tala Security.  Their study is called the “Global Data at Risk – 2020 State of the Web Report”, and it can be downloaded at this link:

Almost 1,000 top and popular websites were audited for their various levels of security, and tests such as vulnerability to Magecart, formjacking, cross-site scripting (XSS), and credit card skimming as well as other threat variants were examined as well.

Here are some of the key takeaways of their study, as it relates to web application security:

*Web application security is declining, and has reached a new high since 2019, even despite the passage of the CCPA and GDRP, which impose huge financial penalties;

*The risk of using JavaScript and the security weaknesses that it possesses has greatly increased since 2019, and has escalated to the highest levels at this point, primarily triggered by the COVID19,

*58% of the web application content that appears on the web browser of the end user (it does not matter which one, it could be Chrome, Edge, Firefox, Safari, etc.), come from 3rd party JavaScript integrators;

*On the websites that were surveyed, 92% of them use contact forms that are easily susceptible to what is known as “Formjacking”.  This is the instance where you fill out a contact form, and from there, it can be intercepted by a malicious third party, in order to gain further access to your Personal Identifiable Information (PII).  This includes such items as driver’s license numbers, credit card information, banking information, your location details, and such.  While filling out a contact form is a normal process for a prospect to engage into inquiries, the attacks on this part of the web application has increased at least by 10X;

*The biggest threat variant that exists to web applications is what is known as “Cross Site Scripting”, or “XSS” for short.  An alarming 97% of the websites that were audited are prone to suffering from a large-scale attack in this regard;

*What is even more alarming, some of the most trusted websites that were surveyed are at grave risk as well, and the pool that was surveyed, 99% of them have been technically whitelisted, but are still extremely vulnerable.  One such example of this is Google Analytics

*Only 30% of the web applications examined had any sort of security protocols established from within their source code;

*Only 1.1% of the websites that were examined has any sort of effective security protocols embedded within it.

My Thoughts On This

Yes, these numbers are quite alarming.  But if you dissect these findings, you will find some of themes in it, such as the following:

*JavaScript is the source code development tool that has been heavily utilized in this survey.  But it is not just here it is used, it is used all across the board in order to create websites that “ . . . powers richness but also the framework of what renders on customer browsers, including images, style sheets, fonts, media and content.”  (SOURCE:

In other words, it is the JavaScript that is used which makes us what see on a website so powering and easy to use.  This is technically known as the “Client Side” and the study also discovered that this what is most prone to Cyberattacks.  But you may be asking at this point, what exactly is JavaScript?  It can be technically defined as follows:

“JavaScript is a scripting or programming language that allows you to implement complex features on web pages — every time a web page does more than just sit there and display static information for you to look at — displaying timely content updates, interactive maps, animated 2D/3D graphics, scrolling video jukeboxes, etc. — you can bet that JavaScript is probably involved. It is the third layer of the layer cake of standard web technologies, two of which (HTML and CSS)”


Put it another way without JavaScript, websites would be just static in nature, and of course boring.  It is the JavaScript that makes a particular web application exciting to see and very easy to navigate through.

*A majority of the JavaScript is made available by third parties known as “Application Programming Interface”, or also known as an “API” for short.  In easy to understand terms, this is a bundled software package, that contains the JavaScript.  The APIs are typically used to bridge the gap between the client side, and the database of the particular web application that houses the PII datasets that are transmitted across the contact page in the web application.  The API actually saves a lot of time, because it literally contains pre canned JavaScript code that can be used almost instantaneously.  If it hadn’t been for the API, software developers would then have to custom create this bridging code, which in turn means more expense for the client.

*It is even the so-called whitelisted domains that are also prone to attack on the client side, as previously described as well.  This simply means that because a web application is deemed to be safe to use (that is why they are on a “whitelist” of sorts), they are still prone to Cyberattacks.

So what can be done to alleviate all of this?  The answer is quite simple:  Test, Test, and Test the source code of the web application before it is released to the client and goes into production mode onto their side.  But this does not mean that the software development team waits until the very end when the project is completed in order to test the source code. 

This must be done as each source code module is completed, and this process must be repeated in an iterative style fashion.  By doing it this way, the software development team will not only be able to deliver the project to the client on time, but also, any security vulnerabilities that are found (especially those of backdoors) can be found and rectified in preceding source code module and stopped down in their tracks before it has a cascading effect onto other, subsequent source modules.

In this regard, probably one of the best methodologies that you can use is that of Penetration Testing.

With regards to the APIs, a bulk of them are available for download for free, because they make use of the Open Source concept.  While this is certainly advantageous, it has one major pitfall:  They are not tested by any means.  The organizations that deliver these kinds of APIs usually leave it to the software development team to test the source code in them. 

But very often, they do not, because they are under so much pressure to deliver on time and under budget for the client.  The moral of the story here in this aspect:  Always source code test the APIs before you implement them.  You need to explain this to the client, and more than likely, they will greatly appreciate the extra time and efforts that you are taking, especially in today’s environment.

But despite the prevalence of the both the GDPR and the CCPA as well as the harsh financial penalties imposed, keep this other aspect in mind as well:  If you deliver a web application to a client that has been hacked into, you will be held responsible for it, from both a legal and financial point of view. 

Therefore, to avoid this, you should stipulate in your contracts with the client that you will not only test the source code before you release it to them, but that also they should conduct their own tests as well, and report any vulnerabilities back to you for correction.  This should mitigate the risks of any potential legal actions that you could face down the road, as a result.