JavaScript rules




Area of impact

Affected element

Covered by Quality Clouds

Covered by free scan utility


Javascript - Optimize loops






Javascript - Avoid use of eval() function






Javascript - Use === comparison




203Javascript - Avoid use of alert functionLowScalabilityAll (tick)(tick)
204Javascript - Avoid use of local storage on Client ScriptsHighSecurityAll (tick)(tick)
205JavaScript - Avoid unrestricted targetOrigin on cross-domain messagingHighSecurityAll (tick)(tick)
206Javascript - Avoid use of Function ConstructorsHighSecurityAll (tick)(tick)
207Javascript - Avoid use of WebDBHighSecurityAll (tick)(tick)
208Javascript - Avoid use of debugging statementsHighSecurityAll (tick)(tick)
209Javascript - Avoid making connections on unsecure protocolsWarningSecurityAll(tick)(tick)

Use === comparison

The == comparison operator always converts (to matching types) before comparison.

The === operator forces comparison of values and type.

Avoid use of eval() function

The eval() function is used to run text as code. In almost all cases, it should not be necessary to use it. Because it allows arbitrary code to be run, it also represents a security problem.

Optimize loops

Loops can become slow if not done right.

One of the most common mistake is to read the length attribute of an array at every iteration. This means that every time the loop runs, JavaScript needs to read the length of the array. You can avoid that by storing the length value in a different variable.

And an even shorter way of achieving this is to create a second variable in the pre-loop statement.

Another thing to ensure is that you keep computation-heavy code outside loops. This includes regular expressions and — more importantly — DOM manipulation. You can create the DOM nodes in the loop but avoid inserting them into the document. 

Avoid use of alert function

The use of alerts functions is discouraged in Production environments, as it could inadvertently expose sensitive data or program internals.

Avoid use of local storage on Client Scripts

HTML 5 allows developers to store megabytes of data on the client-side. This can be a security vulnerability as the data is not encrypted by default.

Avoid unrestricted targetOrigin on cross-domain messaging

HTML 5 allows for the exchange of messages between different Window objects. The window.postMessage() function can be used to achieve this, but using the wildcard * targetOrigin in this function can allow a malicious site to intercept messages being passed between your application Windows. Therefore, uses of the window.postMessage method such as window.postMessage("Message", *); should always be avoided.

See this reference for further details.

Avoid use of Function constructors

Function constructors are similar to the Eval function in that will transform any String into executable code. From this point of  view, they are a serious security vulnerability.

Additionally, each time the Function constructor is called on a string representing source code, the script engine must start the machinery that converts the source code to executable code. This is usually expensive for performance - easily a hundred times more expensive than a simple function call, for example.

Using the Function constructor  does not affect the code surrounding the use, but it can still be quite slow.

Avoid use of WebDB

The Web SQL Database ( was a failed attempt by the W3C to introduce a set of APIs to manipulate client-side databases using SQL. It is not implemented by all browsers, but any possible references to it should be avoided, as only a user name is required to access the data stored in these repositories.

Avoid use of debugging statements

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

Avoid making connections on unsecure protocols

Any connection from JavaScript code through an unsecure protocol, such as http, or ftp should be avoided. System properties and user preferences which include these insecure protocols are also reported.