JavaScript Security: How to Mitigate the Top Risks Now

If you run an interactive website or application, you must prioritize JavaScript security. Program errors, unsanitized user inputs, and malicious attacks abound in JavaScript, and you’re here because you wouldn’t want to be the next victim of a JavaScript-based cyber attack.

Automated tools such as JavaScript error monitoring plugins can only go so far in identifying JavaScript vulnerabilities, so every JavaScript developer, from proselyte to professional, must understand common security issues in JavaScript and follow best practices. That’s why we’ve prepared these two JavaScript security checklists.

Below, we’ll review the most common JavaScript exploits and walk through some essential and fundamental JavaScript security best practices. Let’s get started.

What Do I Need to Know About JavaScript?

JavaScript is a cross-platform, object-oriented scripting language that powers interactive and responsive elements on webpages, such as real-time updates, multimedia embeds, complex animations, clickable buttons, pop-up menus, and other dynamic features now commonplace all over the Internet. No wonder JavaScript has become fundamental to web development.

In the past, JavaScript applications ran on the client side. With the advent of Node.js, Angular.js, Vue.js, and similar web development frameworks, JavaScript has become a staple in server-side web development. Whatever vulnerabilities JavaScript has can affect both client and server, and it’s imperative to make both ends secure.

Web application security is crucial because we have sensitive data to protect, such as personally identifiable information and internal documents. Data theft, interruptions in business continuity, and other cyber attacks can be costly to the point of being unaffordable. Prevention and preparedness increase the survivability of an entity with an online presence.

Top 10 JavaScript Security Vulnerabilities

The Open Worldwide Application Security Project (OWASP) releases a Top 10 list of web application security risks each year. While not all of these are JavaScript-related, many of the recurring issues we see each year could be avoided by prioritizing JavaScript security. Let’s review some of the common JavaScript vulnerabilities, many of which have, and continue to, appear on the list.

1. Cross-Site Scripting (XSS)

Cross-site scripting is when an attacker inserts malicious scripts into a web application (such as the comment field on a web form), which can then target other website users. These can be used to steal information from other users or steal session cookies.

Cross-site scripting comes in three forms; persistent, reflective, and DOM-based. 

Persistent: A user is able to store input on the target server (such as a message in a forum or a comment field in a form). In this case, other visitors to the site will be affected by the malicious script.

Reflective: This script is not stored and has an immediate response. In order to properly pull off this attack, the attacker must trick a user into sending the malicious script to the site themselves. This is usually accomplished by designing a link that, when clicked, would input the script as the user is sent to the site. The script is executed in the user’s browser.

DOM-Based: This attack takes advantage of the “Document Object Model.” In a DOM-based XSS attack, the server is never affected; everything takes place in the victim’s browser (similar to reflective XSS). The attack is possible if the application writes data to the DOM without proper sanitization.

All of these attacks can be prevented by

  • Properly sanitizing user input (for example, not reading user input as code) 
  • Using output encoding (translating special characters into an alternative, such as translating the < character into the &lt; string)
  • Using a Content Security Policy

2. Cross-Site Request Forgery (CSRF)

This involves tricking a user into carrying out an action on a web application. An example might be crafting a link that includes a change in login credentials or a transfer or funds. In cases like this, the victim is authenticated to the site and has the right to make the requested changes to their account - they simply aren’t aware that the requested action has been embedded in the URL. 

This is different than a reflected XSS attack. The CSRF attack uses a victim’s authentication on a target website. The request is made elsewhere (through a malicious link), but the vulnerable website believes the request was made internally (on its own site). Hence cross-site request forgery.

A required condition for these attacks to be successful is that the application relies only on cookies to identify the user, ignoring the origin of the request. CSRF tokens prevent this attack, as they provide a unique identifier to each request. Without the token, the attacker cannot craft a valid request to the server.

3. Insecure Direct Object References (IDOR) 

Here, an attacker manipulates an application to gain access to data. This is possible when the application does not perform authorization checks, and exposes internal object references.

For example, if a bank used URLs such as, “www.bank.com/account?id=1234567” where “1234567” is the actual account number, an attacker could replace that number in the URL with any random bank account. If the application isn’t performing proper checks, the attacker can gain access to information they should not otherwise have.

The same applies to any type of internal object reference, such as filenames or user profiles. 

Using strong access controls, indirect object references, and validating input can prevent these types of attacks.

4. Security Misconfigurations

These can often be as simple as using default credentials/settings, incorrect settings, or outdated software.

If an attacker can identify a system and the version, they have the ability to look at the default settings, default logins, installation and configuration documentation, and try and find weaknesses and easy-wins.

Follow the advice offered by the application designers and documentation to ensure you are using the correct settings, changing credentials, and turning off unnecessary features which could be abused. And always update to the latest versions and apply security patches as they become available.

5. Sensitive Data Exposure

This is not the same as a data breach. Sensitive data exposure occurs when the data on a server is not properly secured, or an application exposes this information unintentionally. 

Some examples would include PII (Personal Identifiable Information), such as social security numbers, being stored on a server in plain text (without encryption). An attacker who gains access to the system will have access to this information without performing any kind of brute force or decryption.

Another example would be a login that uses weak or no encryption. That username and password could be intercepted by an attacker who could view, copy, or modify the information in transit to gain access.

These attacks can be avoided by encrypting sensitive data at rest (where it is stored) and using proper encryption and security measures to access that information (SSL, TLS, etc.).

6. Broken Authentication

This allows attackers to gain unauthorized access to sensitive data or impersonate legitimate users. Some examples of broken authentication include

  • Allowing weak passwords which can easily be guessed or brute-forced
  • Session fixation - when an attacker sets the session ID of a user before they log in
  • Session hijacking - when a web application does not properly validate session IDs or uses IDs that are predictable; an attacker can steal or “hijack” the session of a legitamite user using the same ID
  • When an application has no policy in place to limit login attempts (either the number of failed attempts per user account or per IP address), attackers can attempt to brute force entry

7. Insufficient Logging and Monitoring

Without keeping logs and actively monitoring activity, attacks will not be caught and can continue their attack for extended periods. This allows attackers to set up persistence and continue gathering information or pivoting to other systems unchecked.

This can be prevented through the use of automated monitoring systems, alerts, and regular reviews.

8. Insecure Deserialization

When an application deserializes (reconstructs an object from a stream of bytes) from untrusted sources and without proper sanitization, an attacker can have the application execute malicious code. This can lead to any number of attacks, including remote code execution and denial of service.

For example, if a web application creates an object from user input, such as filling in credentials, and does not properly validate the information, the input could be malicious and thus the object it constructs could grant access to the attacker or damage the system.

9. Using Components With Known Vulnerabilities

Using third-party applications with known and established vulnerabilities opens your system to attack. Even small plugins or depenancies can have known flaws which can be exploitable. 

There are several tools available to scan and audit your applications for such vulnerabilities.

10. Server-Side Request Forgery (SSRF)

Server-side request forgery abuses the trust relationship between web applications, servers, or other internal or external resources. 

If a server is vulnerable, an attacker can send a malicious request through the web application to that server, which will then request a resource or action from the back-end resources it interacts with. The back-end trusts the vulnerable server and processes the request.

This is primarily used to access resources and documents, or check for open ports. A typical SSRF attack would look like this:

A normal request is made by the attacker to a webpage, such as changing the on screen language, checking stock at a retail location, etc. The request is intercepted and manipulated by the attacker to ask for something different from the server. The language change, for example, may be replaced with a call for the /etc/passwd file. The server trusts the web application and so discloses the information.

Using an SSRF attack, information that sits behind a firewall, requires administrator privileges, or is otherwise not directly accessible can be discovered.

Top 10 JavaScript Vulnerabilities

JavaScript Security Best Practices

So how do we protect our JavaScript applications?  There are several best practices to follow which can mitigate the threats we’ve discussed.

Input Validation and Sanitization

Remove or modify characters and elements which could be harmful, such as characters used in scripts: < ! -- etc. 

Ensure input meets the expected format. This can protect against XSS, IDOR, and SSRF attacks.

Output Encoding

Changing dangerous characters into a safe equivalent so it cannot be read as an element and executed by the application. This is a great prevention against XSS attacks.

Content Security Policy

By restricting the sources of content that can be loaded to an application, injection attacks such as XSS become much more difficult. This might mean setting a policy that content can only be loaded from the same origin as the web page.

CSRF Tokens and SameSite Cookie Attribute

CSRF tokens are unpredictable values assigned to a session. When a request is made, the token in the session is compared with the one on the server to ensure the request has been made from the correct origin. This prevents crafting a malicious command in advance as the attacker does not have the CSRF value that will be assigned. The SameSite cookie attribute tells the browser to only send cookies in requests coming from the same site.

Robust Access Controls

IDOR and Sensitive Data Exposure can be prevented by properly securing data and setting strict rules as to who can access the information. 

Secure Password Storage and Multi-Factor Authentication

Securing passwords using hashes and salting techniques can protect passwords in case of a data breach. So long as the passwords themselves are complex, properly hashing them can make any kind of cracking very difficult and time-consuming.

Requiring multi-factor authentication to access secure information adds a layer of protection against attackers. With MFA, a password is not enough. Attackers would need access to a user’s phone, hardware token, biometrics, or other authentication method.

Encryption for Data at Rest and in Transit

Encrypting sensitive data means that in the event of a breach, the stolen data is still secured so long as the encryption remains in tact. Proper use of encryption can make it nearly impossible to crack without having the key. Using protocols such as HTTPS and TLS for data in transit ensures even if it is intercepted, it will be unreadable to the attacker.

Regular Security Audits and Dependency Management

Monitoring your resources, looking for anomalies, using appropriate tools and vulnerability scanners, following security best practices, and ensuring all third-party applications are both reputable and up-to-date can protect against security misconfiguations and known vulnerabilities.

Building Security Into Application Design

Don’t leave securing your applications until the end. Instead, consider security to be an integral part of the design phase and plan accordingly. Examine all code throughout development and evaluate any third-party applications or libraries you intend to use before integration.

Documentation and Log Review

Keep detailed documentation of how applications have been designed and how they are expected to operate. Use automated tools to watch for anomalies and set alerts. Establish a baseline behaviour to check against. Keep up to date on new vulnerabilities that may affect your applications.

Top 10 JavaScript Security Best Practices

Conclusion

Implementing JavaScript security best practices will fortify your JavaScript apps against common attacks, such as those we’ve listed above. We also recommend that you keep up-to-date with web application security. See our courses below to hone your skills. We wish you all the best wherever you go, armed with the information above.

Frequently Asked Questions

Level Up in Cyber Security: Join Our Membership Today!

vip cta image
vip cta details
  • Cassandra Lee

    Cassandra is a writer, artist, musician, and technologist who makes connections across disciplines: cyber security, writing/journalism, art/design, music, mathematics, technology, education, psychology, and more. She's been a vocal advocate for girls and women in STEM since the 2010s, having written for Huffington Post, International Mathematical Olympiad 2016, and Ada Lovelace Day, and she's honored to join StationX. You can find Cassandra on LinkedIn and Linktree.

  • Kristopher Morrison

    Kristopher is the Content Manager at StationX. He's a journalist, technology and business blogger, and CNVP who loves all things cyber. Combining his passion for technology with his skills in writing, he wants to bring you the most accurate and valuable information possible. You can always reach him on LinkedIn.

>