close search bar

Sorry, not available in this language yet

close language selection

The sacred knowledge of securing JavaScript

JavaScript is gaining more and more popularity not just on the front-end, but also on the back-end, with new frameworks coming out almost every month. On the client-side, we are watching an overwhelming encroachment of AngularJS, which is slowly pushing out Knockout.js, React.js, and Ember.js. On the server-side, Node.js has established its base with Express as the main companion. But new web frameworks and specialized frameworks like Hapi.js, Sails.js, and Socket.IO are growing like mushrooms after a good rain. And then there are the new kids on the block to consider like Meteor and Aurelia that are popular for prototyping and are beginning to make their way to real production environments.

On the other hand, cross-site scripting has been in the top 3 of the OWASP Top 10 vulnerabilities for a decade. With the emergence of DOM-based cross-site scripting several years ago, and the large amount of complex JavaScript client-side code, we are not really reducing the number of vulnerabilities. There are several reasons for that.

Reason 1: Inadequate knowledge of security development standards

There is a lot of documentation on how to use the frameworks, but there isn’t much literature yet about how to use them securely. Some good resources exist for tracking security issues and fixes, such as Node Security Project, but there isn’t a vast knowledge of security development standards and guidelines, as we have for more mature languages like Java and .Net.

Reason 2: Lack of effective automated tools

There currently aren’t any automated tools that effectively scan client-side and server-side JavaScript, performing dataflow analysis and not just pattern-matching, and understanding the thousand and one frameworks. You are welcome to prove me wrong on this one.

Reason 3: Complex dependencies between frameworks

One of the reasons why there aren’t many really good tools is because of the third reason—the complex dependencies between frameworks. Although they are open source and all of the source code is on GitHub, when one framework is built on top of another and it also uses multiple middleware components, which in turn use other libraries and packages, we are bound to get vulnerabilities such as the zero-day in the Socket.IO’s dependency on Node.js.

AppSec Europe 2016

One way to find resources and educate yourself on the security posture of new frameworks and technologies is by attending one of the biggest and most technical security conferences—AppSec EU this June. Such events offer an opportunity to not only listen and learn from highly-skilled speakers, but also to mingle, argue, and discuss the issues that worry you most. Or check out our full-day Defending JavaScript course.

Learn how to write defensive JavaScript

Ksenia Peguero

Posted by

Ksenia Peguero

Ksenia Peguero

Ksenia Peguero, is a senior research manager at Synopsys, where she is managing the R&D team for the Rapid Scan Static engine, the next gen approach to SAST. Her research expertise ranges from security of web stack, to mobile languages, to cloud environments, and infrastructure as code. Before diving into research and engineering, Ksenia had a consulting career in a variety of application security practices including penetration testing, threat modeling, code review, and static analysis tool design, customization, and deployment. During her decade in application security, Ksenia has established and evolved secure coding guidance and practices for many firms, developed and delivered numerous software security trainings, and presented at conferences around the world, such as RSA and OWASP AppSec Global. Ksenia holds a Ph.D. in Computer Science from George Washington University.

More from Security news and research