Is JavaScript reliable and secure

JavaScript: Security

Here is a JavaScript documentation by molily. At the moment it is still patchy, but it is gradually growing. Comments and feedback are welcome by email.

To the table of contents


JavaScript is often viewed as dangerous and unsafe, with the result that some web authors do without JavaScript and web users restrict the execution of JavaScripts. In fact, JavaScript is not harmless. JavaScript is a full-fledged programming language and JavaScript programs run on websites. This is the biggest gateway for malicious code on the web.

Since its inception, JavaScript has also been used to control and mislead users. Modern browsers have therefore taken countermeasures that curtail the possibilities of JavaScript in various ways. These restrictions we will get to know.

The area of ​​influence of the core of JavaScript (ECMAScript) is relatively clear. A JavaScript that only uses these techniques has limited options and thus a comparatively low risk potential. The assumption is that the browser basic security concepts note. These are also presented below.

When security flaws are discovered in browsers, in most cases JavaScript is involved. Some of these loopholes allow the basic security restrictions to be circumvented, others concern JavaScript extensions. Because JavaScript is now a door opener for diverse client-side programming that goes far beyond the core technologies.

Browser manufacturers are trying to expand the capabilities of JavaScript by incorporating interfaces to existing technologies. This enables security-critical access to the client computer. Now these interfaces are not available for every script, but are protected by security mechanisms. If these do not work correctly, security gaps arise.

JavaScript security concepts

Sandpit principle

Compared to other programs, JavaScript has only limited possibilities. It operates in the context of a browser window and a document. Within this strict framework, in which the script is locked, it is allowed to operate freely, because it can only cause limited damage. This basic limitation is called Sandpit principle (English sandbox).

In particular, ordinary JavaScript cannot be used without consent Read files on the web user's computerlet alone make changes to it. It also cannot change operating system or browser settings or install software.

There are only a few exceptions in which a JavaScript can operate beyond the browser window and document. For example, it can call certain browser functions and open simple dialog windows and other browser windows. We will get to know these exceptions, which are usually associated with certain restrictions.

Same origin policy

The Same-Origin-Policy (in German roughly: Principle of the same origin) means that a JavaScript in a document may only access those other documents that have the same origin. With same origin In short, it means the domain in the URL of the document.

First of all, a JavaScript has access to the document in which it is integrated and in the context of which it is executed. When using frames, inner frames (iframes) and pop-up windows, a script can also access other documents. The same-origin policy restricts this cross-document access.

Let us assume that the URL is loaded in one frame and the URL is loaded in another frame of the same frameset. These two documents have the same origin, namely. Therefore, scripts from both documents can mutually access the other document, e.g. to read form data or cookies, to make changes via the DOM or to monitor events.

If, on the other hand, the URL of the second document is, then the same-origin policy blocks cross-document access. Because the origin is different, once and once.

The aim of the same-origin policy is to ensure that one website cannot access the data of another so easily. This would of course not be a problem if the other website is public anyway. On the other hand, it would be a serious security gap in websites that require registration and display confidential data - for example webmail services, communities and all customizable web applications.

The same-origin policy also applies, better known as Ajax. With, a script can send HTTP requests, transmit data to web servers and finally receive data. The same-origin policy ensures that only data from the same originating domain can be received using.

There is one point where the same-origin policy does not apply: An HTML document can integrate JavaScript from foreign domains using the element. These are executed with the same rights as JavaScripts from the same domain. For example, the external script can be integrated with the URL.

Such integration of scripts from external web servers is unfortunately common practice: online advertising, statistical scripts and social media widgets are integrated in this way. From a security perspective this is an extremely questionable practice. On the one hand, it is a useful feature because it brings web services to your own website. On the other hand, embedding someone else's code into your own site is a security risk - we will come back to this later in the context of cross-site scripting.

Same-origin policy and subdomains

The same-origin policy not only blocks access that encompasses so-called second-level domains (e.g. not allowed to access). The lock also blocks access between subdomains of the same domains. This means that a script in a document under has no access to a document under, although the domain is the same () and only the subdomain is different (de across from en).

This regulation may seem strict at first, but it is an important safety barrier. Because it is possible that there are different websites under one domain that do not want to share their data with each other. Even if both domains belong to one site, the different domains can be encapsulated and secured in this way.

However, there is the option for a document to consent to be open to access from the same domain. The following JavaScript statement is noted in a document under:

document.domain = '';

This means that the document is accessible for scripts that are on a domain that ends with. So not only for, but also for or.

This scheme does not only apply to second-level domains, but to any subdomains. A script under can note the following statement:

document.domain = '';

This allows access e.g. from and all other domains that end with.

Browser restrictions and protection against malicious JavaScript

JavaScript does not have complete control over the client computer and the browser, but it does have some potential for misuse that can mislead, harass and manipulate the user. In the meantime, browsers have built-in protection mechanisms that limit certain JavaScript capabilities. You should be aware of these, because sooner or later you will reach these limits during JavaScript development.

Popup blocker

One problem is opening new windows with. This method is misused to create so-called Popup window (short: Popups) to open with advertisements that pop up automatically and undesirably. The uncontrolled opening of windows not only annoys users, but is also a security problem because it can paralyze the browser or even cause it to crash.

For this reason, all browsers now have a so-called Popup blocker built-in. These blockers only allow windows to be opened using JavaScript if you do so reacts to user input. So if you just call it, most pop-up blockers will prevent the window from opening:

<script>'dokument.html', 'fenstername'); </script>

However, if you open a window in response to user input (see event handling), the popup blockers usually allow it. For example, you can give an element a handler. A simple example would look like this:

<a href="dokument.html" id="popup-link"> Dokument XYZ im eigenen Fenster öffnen </a>

The JavaScript for this (see advanced event processing):

function openPopupFenster (event) { (, 'popup'); } document.getElementById ("popup-link") .addEventListener ('click', openPopupFenster, false);

Pop-up blockers try between desired and undesirable To distinguish between pop-up windows. A browser cannot reliably distinguish whether a window is wanted by the user or not. The mentioned criterion of User input (e.g. a mouse click on an element) is only of limited use: Some websites trick the browser into thinking that they would open a "desired" popup window as a reaction to user input by opening an advertising popup when clicking anywhere in the document.

There are no general rules by which the various popup blockers work. To avoid pop-up blockers as far as possible, you should only open windows in event handlers for the event for or elements. The above example illustrates this.

Configure browser restrictions

... at which points you can set the JavaScript behavior of the browser.

IE 8: Tools> Popup Blocker> Popup Blocker Settings; Internet Options> Advanced; Internet Options> Security> [Zone]> Scripting / Misc

Firefox 3.0: Extras> Settings> Content> Enable JavaScript> Advanced ...

Opera: Tools> Preferences> Advanced> Content> JavaScript Options ...

Page-specific settings

Website-specific JavaScript settings are an important security feature of browsers. Depending on which website is accessed, the execution of JavaScripts is permitted without restriction, only permitted to a limited extent, or scripts are not executed at all. This takes into account the fact that JavaScript serves as the main gateway for exploiting browser security gaps, is misused to control the user or simply integrates unwanted advertising.

These page-specific settings are implemented differently from browser to browser and not only affect JavaScript, but also other security and data protection-critical technologies such as cookies and plugins.

Internet Explorer

Internet Explorer has various security zones that are linked to certain settings by default. A normal HTML document on the World Wide Web lies in the Internet zone, a document on the local computer or in the local network in the zone Local intranet.

There are also two zones to which the user can independently add web addresses and network paths: Trustworthy sites and Restricted sites. This allows the user, for example, to select rather restrictive security settings for the Internet zone, which can then be relaxed for certain pages.


Mozilla Firefox has page-specific settings internally, but by default does not offer a menu that the user could use to comfortably regulate the settings. The Firefox add-on NoScript is enjoying some widespread use. This allows the execution of JavaScripts to be permitted or forbidden on a page-by-page basis and can impose further restrictions on scripts.

Cross-Site Scripting (XSS)

Cross-Site Scripting, abbreviated to XSS, is the smuggling of foreign, possibly harmful JavaScripts into a website. It is not so much a security problem within JavaScript as it is a security hole in faulty web applications. If web applications incorporate unfiltered data from untrustworthy sources (e.g. from form entries or HTTP parameters) into the HTML, attackers can, in the worst case, smuggle in JavaScript code permanently.

This code has all the access rights that JavaScript usually has on the website. If the application is protected by login, the script can take action on behalf of the user. Because an injected script can send HTTP requests, read out, change and send private data. The user usually takes no notice of this. The web application cannot easily distinguish whether the user himself is the author of the actions or a malicious JavaScript.

XSS holes in large web applications like Facebook and Twitter have made spectacular JavaScript worms possible. These propagated within the website, e.g. via user profiles, could read or delete private data and thus cause great damage. There are also XSS worms that infected other domains with the same web application (e.g. the blog software WordPress) and thus spread across web servers.

In order to avoid XSS gaps, it is necessary to carefully check, filter and defuse all untrustworthy data that is built into the HTML, CSS and JavaScript code on the server or client side. ...