Learn about the high-level concepts and implementation details of building secure mashups using the Dojo framework. Understand both the source of mashup security threats and techniques for circumventing them when developing mashups with Dojo.


J. Jeffrey Hanson, CTO, Max International

Jeff HansonJeff Hanson has more than 20 years of experience as a software engineer and architect, and is the CTO for Max International. Jeff has written many articles and books, including Mashups: Strategies for the Modern Enterprise. You can reach Jeff at jjeffreyhanson@gmail.com.

03 August 2010

Also available in Chinese Japanese

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See Get started with Dojo development

The term mashup is commonly used to describe the technique of producing a new song by mixing together two or more existing songs. For the purpose of web applications, mashup describes the method of combining existing UI artifacts, processes, services, and data to create new web pages, applications, and so on. Many different consumer and social media environments employ the technique.

Mashups allow for rapid development of new web pages and applications through the use of recyclable UI elements and loosely coupled services. They create an agile and dynamic development environment that lets users with limited technical skills develop powerful and useful web pages and applications. Most mashups are implemented by combining existing UI artifacts with high-level markup and scripting languages such as HTML and JavaScript code.

Threats facing mashup development

The mashup development model introduces an open environment that poses new security threats, making security a primary concern for developers. Because mashup pages can be used as artifacts or data sources for further mashups, it is impossible to predict exactly how these elements will be used in subsequent deployments. It is therefore crucial that developers address issues of security throughout the development life cycle.

You must take new measures to address the increased security risks in the mashup development model; traditional security measures, such as DMZs and firewalls, fail to address the fine-grained access needed for mashup UI artifacts and data. In addition to handling traditional threats, a mashup application or web page must address such issues as cross-site scripting (XSS) and cross-site request forgery (CSRF), among others.

Cross-site scripting

Clever hackers can exploit poor session management. For example, when a user is redirected to a login page, the server is already active for an existing user even as the new user is providing credentials to it. The server, believing that the session is already active, returns a reassuring response to the new user that suggests that a brand new session was created and the credentials were safely stored. The clandestine owner of the existing session—the hacker—can, at this point, record and exploit data that is transferred between the new user and the server as long as the session remains active. XSS techniques are often employed by attackers to sidestep browser safeguards and redirect data to a third-party site for recording.

Cross-site request forgeries

During a CSRF attack, requests originate from an intruding third-party site and are passed through an authenticated browser page to the server. Responses are then returned to the intruder site. Typical security mechanisms assume that once an authenticated session has been established, all subsequent requests from the authenticated browser to the server are valid. Therefore, if an intruding site can get the authenticated browser to pass requests and responses back and forth between it and the server, that site has the same privileges as the authenticated browser, and privacy is compromised. The browser's same-origin policy does not prevent CSRF attacks because the attack requests are transmitted to the same origin in proxy for the intruding third-party site.

Get to know Dojo

The Dojo Toolkit (see Resources for more information) is an open source JavaScript framework of application programming interfaces (APIs), skins, and widgets for building applications and websites using JavaScript code, HTML, CSS, and Ajax. It consists of charts, animations, hierarchical trees, calendars, menus, and other elements. For cross-browser Ajax development, Dojo presents an abstracted layer on top of the XMLHttpRequest (XHR) object.

Dojo is built around a hierarchical packaging system that allows for modular development using namespaces. This lets third-party libraries and applications extend the functionality of Dojo without overlapping object or function names. Dojo packages consist of one or more files, with optional dependencies on others.

Dojo also provides a mechanism for building profiles—groups of packages combined for unified loading, initialization, and caching. Using profiles, a system such as Apache Ant can create a single compressed JavaScript file containing the packages and dependencies specified in a given profile. Pre-built profiles are available for some common use cases.

CSRF protection with Dojo

You can typically prevent CSRF attacks by requiring that a unique token or cookie be passed with every request, which can be done with Dojo. Because all XHR requests are routed through the dojo.xhr() call, you can override this call to include an extra header that is used as the unique token, as shown in Listing 1.

Listing 1. Including an extra header to override XHR requests
var originalXHR = dojo.xhr;
dojo.xhr = function(httpVerb, xhrArgs, hasHTTPBody)
  // Use the session ID (JSESSIONID for Java, PHPSESSID for PHP)
  // as the token value
  args.headers["Request-Token"] = dojo.cookie("JSESSIONID");
  return originalXHR(httpVerb, xhrArgs, hasHTTPBody);

With this code in place, the server will check each request to verify that the Request-Token header exists and has the same value as the session ID. The server will assume that any requests that lack the correct value in the Request-Token header are CSRF attack attempts and will reject them.

DojoX Secure

DojoX is a framework of extensions to the Dojo Toolkit that works as a code repository, an incubator for experimental code, and a testing environment for other Toolkit extensions.

DojoX Secure is a group of tools and subprojects of the DojoX framework that is intended to address security issues that arise from handling potentially malicious data and code. DojoX Secure provides three main packages:

  • The dojox.secure.sandbox package provides features and tools for safely loading JSON data, web pages, and scripts from external domains using the XHR object. It provides a sandboxed environment for the browser’s DOM to prevent its malicious manipulation.
  • The dojox.secure.capability package ensures JavaScript validation before a script can access or modify JavaScript objects outside of the sandboxed environment.
  • The dojox.secure.DOM package restricts access to specified branches of the browser’s DOM.

The Dojo XHR plug-in registry

Dojo version 1.2 presents a new XHR plug-in registry that lets you use different transport mechanisms to address the features and functions of a given browser or server. The plug-in registry is intended to support cross-domain specifications and protocols as they become available. Using the registry, you can specify different transport mechanisms while leaving the rest of the scripting code intact, which decouples resource-transport scripts from resource-manipulation scripts.

DojoX Secure includes components that are necessary for safely loading potentially malicious code, content, and UI artifacts from external domains. It also ensures that scripts are safe to execute and provides a sandbox to control access and modification of the DOM. These features make DojoX Secure a valuable contributor to secure mashup construction.

The next sections describe how to use the dojox.secure packages to thwart specific mashup security threats.

Loading cross-domain resources

DojoX Secure relies on the DojoX XHR plug-in registry framework to retrieve resources from cross-domain sites. This transport framework supports emerging technologies (for example, the XDomainRequest object for Windows® Internet Explorer® version 8 and the W3C's Cross-Origin Resource Sharing specification) that help access these resources. Until browsers have standardized on one or more of these emerging technologies, an alternative is required; DojoX provides two transport plug-ins that you can use immediately for accessing resources across domains:

  • The proxy server transport plug-in relies on a proxy server service on the original domain. With such a service running, resources can be requested from a foreign domain, specified as a parameter of the addProxy function of the xhrPlugins object. For example, the following snippet illustrates sending a request to a proxy server service to connect to example.com and retrieve a resource named someresource:

  • The window.name transport plug-in can be used for web pages or applications that support the window.name protocol. This protocol creates an iframe and then sets the iframe name to the data to be retrieved, such as myiframe.contentWindow.name = "This is some data." The main HTML file can then retrieve the myiframe.contentWindow.name value. To define that resources should be loaded from example.com with the window.name protocol, register the example.com site as follows:


Once you define the transport mechanism for retrieving resources, create a sandbox to load resources into.

Playing in the sandbox

Creating a sandbox with DojoX Secure requires two steps:

  1. Define a DOM element to be used as the sandbox. This element can be a simple standard <div> declaration:
    <div id="mySandbox"></div>
  2. Create a sandbox. This step is accomplished with a one-line DojoX function call with the <div> ID passed as a parameter:
    var mySandbox = dojox.secure.sandbox(dojo.byId("mySandbox"));

Now that the sandbox is created, load HTML snippets into the sandbox using the loadHTML function:


The loadHTML function loads an HTML snippet from a given URL and injects it into the sandboxed DOM element. If the snippet contains scripting code, the scripts are also sandboxed.

You can also load JavaScript files and execute them within the sandbox using the loadJS function call:

var result = mySandbox.loadJS("http://example.com/snippet.js");

The loadJS function loads the contents of the JavaScript file that was specified. The JavaScript code is first validated to ensure that it is safe, and then executed within the confines of the sandbox; the sandbox limits the loaded and executed code to the sandboxed DOM element and any of its child nodes. The dojox.secure sandbox mechanism is shown in Figure 1.

Figure 1. The DojoX Secure sandbox
The DojoX Secure sandbox provides a location for the safe execution of JavaScript code

Any valid values or objects created within the sandbox, such as the result of the loadJS call, are accessible to the JavaScript environment of the main document. This eases interaction between the main document and the sandbox environment.

To provide a secure environment, some standard JavaScript functionality (for example, using the eval(), restricting access to global variables, using the [] operator, and declaring a <link> tag) becomes unavailable or restricted within the DojoX Secure sandbox environment.

In addition to loading sandboxed resources, DojoX Secure provides functionality that you can use to build sandboxed UI artifacts.

Creating secure UI artifacts

Because DojoX Secure sandboxed scripts have access to the sandboxed element, you can perform DOM element creation and manipulation directly on the sandboxed element. By restricting DOM manipulation to child elements and nodes of the sandboxed element, you can securely manipulate the browser's DOM within the sandbox.

Listing 2 shows a simple UI artifact that you can create within a DojoX Secure sandbox.

Listing 2. A sandboxed UI artifact
<div id="mySandbox">
  <script type="text/javascript">
    var widget = document.createElement('div');
    widget.setAttribute('id', 'testwidget');
    widget.style.width = 300;
    widget.style.height = 300;
    widget.style.background = "#0f0";
    widget.style.border = "4px solid #000";
    widget.innerHTML = "This is some data for the widget.";

The functionality demonstrated in Listing 2 illustrates a UI artifact that was dynamically created and loaded within the original domain. However, UI artifacts can be created and loaded from other domains just as easily. This code lets you write UI artifacts for use within any DojoX Secure sandbox and count on secure loading and execution.


Mashups let you create new UIs by recycling and reusing existing artifacts with high-level scripting languages. Mashups also help you to integrate disparate data quickly and easily using semantically rich data formats that require neither complex programming nor middleware technologies.

Mashup development introduces an open development model whose weaknesses bring security concerns to the forefront when developing a mashup application. Because mashup pages can also be used as sources for subsequent mashups, it is difficult to predict exactly how mashup artifacts, pages, and data sources will be used in the future. As a result of each mashup's potential for offspring, the need to address security throughout the entire process becomes imperative.

The DojoX Secure JavaScript framework heightens your ability to build secure mashups. Its APIs, tools, and subprojects let you load resources and execute scripts in a sandboxed environment. DojoX Secure also provides interaction with a browser's DOM in that very environment, thereby reinforcing the secure development and deployment of UI artifacts.

These concepts and details are part of an ongoing conversation that addresses techniques for circumventing mashup security threats by developing with dojox.secure framework.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development
ArticleTitle=Build secure mashups with Dojo