JavaScript Security

JavaScript, the browser-side scripting language, is rising in popularity, and for good reason. JavaScript can be the foundation of a web application, where lightning-fast response time meets interactive elements to engage users in new ways. However, some are hesitant to jump into the world of JavaScript. In the past, JavaScript was easily exploited to manipulate users on websites. Below we cover some common types of JavaScript exploits, the risks these pose, and how to keep your website secure.

JavaScript Security Issues

Some of the most common exploits and types of attacks are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), though sometimes you may also see Server-Side JavaScript Injection and issues with Client-Side Logic. We will explore these various attacks below.

XSS Attacks

Cross-Site Scripting, or XSS, is one of the most common browser-side vulnerabilities. These types of attacks happen an attacker injects malicious code into a legitimate (but vulnerable) application. Attackers can manipulate JavaScript and HTML to trigger the malicious code or scripts. In this way, the vulnerable application or website is used as the “vehicle” to execute the script on the end user.

CSRF Attacks

Cross-Site Request Forgery involves taking over or impersonating a user’s browser session by hijacking the session cookie. CSRF attacks can trick users into executing malicious actions the attacker wants, or into taking unauthorized actions on the website. In this example, the session cookie is the “vehicle” an attacker uses to impersonate a legitimate user.

Server-Side JavaScript Injection

Server-Side JavaScript Injection is a newer type of JavaScript exploit, primarily targeted at Node.js apps and NoSQL. While XSS attacks are executed in the end user’s web browser, Server-Side attacks are executed on the server level, which can have more disastrous effects on a website. In this type of injection, an attacker could upload and execute malicious binary files on the web server. Vulnerable code is again the “vehicle” used by the attacker in this example.

Client-Side Logic Issues

When developers choose to perform secure processing client-side, this can open up the browser to attackers who might be listening in. For example, if your website code hardcodes API keys into client-side JavaScript, this would be vulnerable to attackers. In this example, poor website coding practices are the “vehicle” attackers use to exploit your website and its users.

JavaScript Security Risks

When JavaScript vulnerabilities like those discussed above exist, your site is vulnerable to attackers. A hacked website can mean brand damage, downtime while your website is being cleaned, and distrust from your users. That means your business is losing dollars and cents, productivity, and the trust of what may have been very loyal customers. There are sometimes legal connotations to security vulnerabilities, especially user impersonation in CSRF attacks. All in all, insecure JavaScript and bad coding practices can cost your business money and integrity.

JavaScript Security Analyzers

There are several security tools which will help examine your website (or web application) from the outside to determine if it is vulnerable to injection and attacks. Before getting started with any of these tools, be sure to check in with your web host to check their Penetration Testing policies. Below we will explore some of the top vulnerability scanning tools.

ZAP

ZAP, or Zed Attack Proxy, was developed by security authority OWASP and offers the ability to easily scan your website for a wide range of vulnerabilities. This tool can be used by a wide range of user levels because of its intuitive interface, and is widely customizable to your project’s needs.

Grabber

Grabber can scan your website for vulnerabilities ranging from SQL injection and XSS to AJAX testing and File inclusion. Grabber tends to be a slower scanner than others, so it should only be used on smaller websites or web applications.

Wapiti

Wapiti allows users to test attack and injection vectors using both GET and POST HTTP Requests. It detects File Disclosure and File Inclusion, XSS, weak Apache configurations, and more. This is a more advanced tool that is executed via command line.

How to Secure JavaScript Code

Knowing the most common attack vectors and vulnerabilities is an important step to securing your website. However, there are also JavaScript development best practices that should be followed to avoid these issues. While there is never a guarantee your code will be secure always, these steps will prevent many attacks by nature.

Avoid using eval()

The eval() function is used by developers to run text as code, which is by nature a dangerous practice. In most cases, substitutions can be made to where these functions are not needed. Wherever possible, replace eval() with more secure functions.

Use SSL/HTTPS

SSL, or Secure Sockets Layer, is a way of encrypting the data users send across the web when interacting with your website. It is extremely important for pages where users input data (login pages, contact forms, cart, checkout, account) to be secured with SSL.

Use CORS Headers

CORS, or Cross-Origin Resource Sharing, is a header you can set that defines the sources allowed to reference your website’s resources. These rules can be placed in your Nginx configuration file, or if you use Apache, in your .htaccess file:

Access-Control-Allow-Origin: http://foo.example

Define a Content Security Policy

A Content Security Policy is a header you can set in your Nginx configuration file, or if you use Apache, in your .htaccess file. This policy allows you to define allowed sources for JavaScript code, styles, fonts, frames, media, and more. Your header will generally look like this:

Content-Security-Policy: default-src: 'self'; script-src: https://apis.google.com;

The above policy says that by default all sources should be the Host/website itself, and for JavaScript it will also accept apis.google.com. All other sources would be rejected.

How to Set Secure Cookies in JavaScript

Another way you can ensure user information is encrypted is by restricting the use of your cookies to secure web pages only. This means the cookie will not be sent if the page is not using SSL/HTTPS. To specify a cookie as “Secure,” or only sent over HTTPS, you can use the following syntax:

document.cookie = "tagname = test;secure";

For reference, the following attributes can be used when setting a cookie:

  • Secure – The Cookie will be sent in secure channel–HTTPS
  • HttpOnly– Don’t allow local scripts read cookies.
  • Domain– Double-check the domain settings.
  • Path – Double-check the path settings.
  • Expires – Determine the user agent how to parse or how to choose the expiry-time.

JavaScript API Security

API security can be a struggle, because JSON is run and returned client-side. That means some of the inner workings of your API will be exposed to the web if anyone looks closely enough. There are, however, a few specific options for sending sensitive information with APIs. When using a JavaScript API system, the security and authentication system you use may vary based on your project needs. In this section we will outline the various API security options, and who should use them.

Securing API Keys in a Client-Side JavaScript Application

The most commonly-used option is to set an API Access and Secret Key pair. These keys allow access to the API, and assign an individual secret token to each end user. If the Access and Secret Key pairs don’t match up, the access to the API is revoked or denied. Companies like Google and Facebook commonly use this method for validation of end users. While Facebook primarily depends on the Secret Key assigned to each user, Google tends to use a Secret Key on the actual server, via OAuth. The key management option is likely the best for organizations with wide, possibly unknown user bases.

Restrict Access to Specific IP Ranges

If your API will only be used within a specific group or building, you can manage API security by simply maintaining an IP whitelist of allowed IP addresses. This option can be tedious if the IP addresses tend to change often however, so it is best for limited groups of known users that don’t change often.

Rate Limit IP Addresses

Another less cumbersome option for API security would be to rate limit IP addresses, so they can only access the API a limited number of times per day before being blacklisted. Before implementing this type of system, you should gather usage statistics to determine if there is a distinct difference between users who really like your API, and attackers who are trying to exploit or abuse it.

WP Engine and JavaScript Security

WP Engine, the first Digital Experience Platform finely-tuned for WordPress, is serious about security. Their dedicated security team monitors for vulnerabilities to notify customers of any concerns. And their platform automatically keeps WordPress up to date with the latest functional and maintenance updates to ensure your website is secure.

Ready to learn more? Check out WP Engine hosting plans.

Get started.

Build faster, protect your brand, and grow your business with a WordPress platform built to power remarkable online experiences.