{"id":34692,"date":"2020-12-09T06:50:47","date_gmt":"2020-12-09T12:50:47","guid":{"rendered":"https:\/\/wpengine.com\/?post_type=resource&p=34692"},"modified":"2025-05-27T21:05:47","modified_gmt":"2025-05-28T02:05:47","slug":"javascript-security","status":"publish","type":"resource","link":"https:\/\/wpengine.com\/case-studies\/resources\/javascript-security\/","title":{"rendered":"Solve These Common WordPress JavaScript Security Issues"},"content":{"rendered":"\n

JavaScript, the browser-side scripting language, is popular for good reason. It can be an excellent foundation for a web application, where lightning-fast response time meets interactive elements to engage users in new ways.<\/span><\/p>\n\n\n\n

However, some users are hesitant to jump into the world of JavaScript. In the past, JavaScript was easily exploited to manipulate users on websites. Below we\u2019ll cover some common JavaScript explo<\/span>it examples, th<\/span>e risks they pose, and how to keep your website secure.<\/span><\/p>\n\n\n\n\n\n\n

WordPress JavaScript Security Issues<\/h2>\n\n\n\n

Some of the most com<\/span>mon JavaScript exploits a<\/span>re Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), although sometimes you may also see Server-Side JavaScript Injection and issues with Client-Side Logic. We will explore these various attacks below.<\/span><\/p>\n\n\n\n

XSS Attacks<\/h3>\n\n\n\n

Cross-Site Scripting, or XSS, is one of the most common browser-side vulnerabilities. These types of attacks happen when 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 \u201cvehicle\u201d to execute the script on the end user.<\/span><\/p>\n\n\n\n

CSRF Attacks<\/h3>\n\n\n\n

Cross-Site Request Forgery involves taking over or impersonating a user\u2019s 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 \u201cvehicle\u201d an attacker uses to impersonate a legitimate user.<\/span><\/p>\n\n\n\n

Server-Side JavaScript Injection<\/h3>\n\n\n\n

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\u2019s web browser, Server-Side attacks are executed on the server level, which can have more disastrous effects on a website.<\/span><\/p>\n\n\n\n

In this type of injection, an attacker could upload and execute malicious binary files on the web server. Vulnerable code is again the \u201cvehicle\u201d used by the attacker in this example.<\/span><\/p>\n\n\n\n

Client-Side Logic Issues<\/h3>\n\n\n\n

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 \u201cvehicle\u201d attackers use to exploit your website and its users.<\/span><\/p>\n\n\n\n

JavaScript Security Issues & Risks<\/h2>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

There are sometimes legal connotations to security vulnerabilities as well, especially user impersonation in CSRF attacks. All in all, insecure JavaScript and bad coding practices can cost your business money and integrity.<\/span><\/p>\n\n\n\n

WordPress & JavaScript Security Risks<\/h2>\n\n\n\n

There are a few significant risks when using JavaScript in WordPress. Let\u2019s take a look at two of the most common: the <\/span>eval()<\/span><\/i> function and poorly-coded WordPress plugins.<\/span><\/p>\n\n\n\n

Eval() in JavaScript Security Risks<\/h3>\n\n\n\n

The <\/span>eval()<\/span><\/i> function essentially takes a string of code and attempts to run it as JavaScript. This function exists in several programming languages and has a few legitimate uses, but developers should be careful with it. That\u2019s because using <\/span>eval()<\/span><\/i> in JavaScript can pose a major security risk. <\/span><\/p>\n\n\n\n

This risk comes primarily from the function\u2019s use to evaluate user input. If a savvy user comes across a text field on your site that is running <\/span>eval()<\/span><\/i>, they could use it to execute malicious code. This is known as Cross-Site Scripting (XSS)<\/a>, and avoiding the use of the <\/span>eval()<\/span><\/i> is one way to safeguard your WordPress site from that kind of attack.<\/span><\/p>\n\n\n\n

WordPress Plugins & JavaScript Security Issues<\/h3>\n\n\n\n

Many WordPress users search for a free plugin when they need a specific piece of functionality for their websites. While most of the time this works out, you need to be careful of (and selective about) what plugins you install on your site. That\u2019s because many of them can cause potential security issues, thanks to their use of JavaScript.<\/span><\/p>\n\n\n\n

Of course, not every plugin will cause JavaScript issues. However, many WordPress plugins use JavaScript, which means you\u2019re relying on the knowledge and experience of the developer to keep your site secure. In general, the best way to avoid any potential issues is to look for plugins that have a large number of active installations, high ratings, and a consistent update history.<\/span><\/p>\n\n\n\n

JavaScript Security Scanners<\/h2>\n\n\n\n

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. <\/span><\/p>\n\n\n\n

ZAP<\/h3>\n\n\n\n

ZAP, or Zed Attack Proxy<\/a>, 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\u2019s needs. <\/span><\/p>\n\n\n\n

Grabber<\/h3>\n\n\n\n

Grabber<\/a> 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. <\/span><\/p>\n\n\n\n

Wapiti<\/h3>\n\n\n\n

Wapiti<\/a> 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. <\/span><\/p>\n\n\n\n

How to Secure JavaScript Code<\/h2>\n\n\n\n

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. <\/span><\/p>\n\n\n\n

Avoid using eval()<\/h3>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

Use SSL\/HTTPS<\/h3>\n\n\n\n

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. <\/span><\/p>\n\n\n\n

Use CORS Headers<\/h3>\n\n\n\n

CORS, or Cross-Origin Resource Sharing, is a header you can set that defines the sources allowed to reference your website\u2019s resources. These rules can be placed in your Nginx configuration file, or if you use Apache, in your .htaccess file:<\/span><\/p>\n\n\n\n

Access-Control-Allow-Origin: http:\/\/foo.example <\/code><\/p>\n\n\n\n

Define a Content Security Policy<\/h3>\n\n\n\n

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:<\/span><\/p>\n\n\n\n

Content-Security-Policy: default-src: 'self'; script-src: https:\/\/apis.google.com;<\/code><\/p>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

How to Set Secure Cookies in JavaScript<\/h2>\n\n\n\n

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 \u201cSecure,\u201d or only sent over HTTPS, you can use the following syntax:<\/span><\/p>\n\n\n\n

document.cookie = \"tagname = test;secure\";<\/code><\/p>\n\n\n\n

For reference, the following attributes can be used when setting a cookie:<\/span><\/p>\n\n\n\n