Defensive JavaScript

Introduction Crypto Library Script Server Type Checker


DJS is a defensive subset of JavaScript: code in this subset runs independently of the rest of the JavaScript environment. When propertly wrapped, DJS code can run safely on untrusted pages and keep secrets such as decryption keys.

DJS is especially useful to write security APIs that may run alongside other untrusted scripts, for instance an OAuth library such as the one used by "Login with Facebook", or a Node.js program that includes untrusted modules.

Techical details can be found in our USENIX Security 2013 paper Language-Based Defenses Against Untrusted Browser Origins. Our security properties do rely on assumptions on JavaScript implementations that have been violated in the past due to bugs and may not hold in ECMA Script 6. We also provide details about attacks and their disclosure on security components that may be loaded in untrusted pages.

In addition, the fragment of DJS without loops and arrays, but extended with our cryptographic library DJCL, can be translated into ProVerif spi-calculus processes, in particular, it can generate the client processes for the WebSpi library automatically to verify the DJS implementations of complex web protocols.

Finally, because DJS is proved to run independently of the JavaScript environment, it provides a more expressive subset for compilation to native code than the existing best effort, asm.js.
Current work: we now compile statically typed JavaScript (similar to DJS) to asm.js.

Contact information

If you have questions, comments or find a bug or attack, please contact Antoine Delignat-Lavaud, Karthikeyan Bhargavan or Sergio Maffeis.

Frequently asked questions

Following our USENIX Security presentation, we have received questions that may be of public interest.

DJS Crypto Library

DJCL is a complete cryptographic library written in DJS, based on SJCL and JSBN, two popular JavaScript libraries for symmetric and asymmetric encryption. It supports AES-256 in CBC and CCM mode, HMAC on top of SHA1 or SHA-256, RSA encryption and signature with OAEP/PSS or PKCS#1 v1.5 padding.

You can try to tamper base object prototypes and default functions on the demo page and verify the independance of the cryptograpic compoutations.
N.B. We do not guarantee robustness against side-channel attacks at this time.

Current version of DJCL - Github - Documentation

Note that the various DJCL components should be loaded together inside a DJS wrapper to be secure against a same origin attacker. See the Script Server tab for a demo of how to embed DJCL and encryption keys into a security component.

Encoding and transcoding

Input encoding:   Output encoding:  


Algorithm:   Input encoding:   Output encoding:

AES encryption


    Tag length:
Direction:   Input encoding:   Output encoding:

RSA encryption and signature

PKCS#1 Private key (generate one with openssl genrsa)

Key details
Public exponent
Private exponent
First prime p
Second prime q
d mod p
d mod q
q^-1 mod p

Encryption (OAEP padding)   Hash function
  Input encoding   Output encoding  
Signature   Input encoding   Output encoding   Hash function


Defensive Script Server

How it works

Defensive scripts must be loaded from a secure isolated origin to preserve source secrecy and other security properties. The primary reason to use defensive scripts is to keep secrets, such as encryption keys, even when loaded into an attacker's page. The purpose of a defensive script server is to embed keys and entropy into the script and making sure that the origin it is being loaded into is authenticated.

We implement a demonstration script server both to serve our examples and be used as a trusted third party script server, where one can register scripts for his own origin with a public key.

The source code of our defensive script server is available at

Example use

We have registered on the defensive script server at to serve a script that retrieves the time in Los Angeles from the host page's server. This script must authenticate the origin it is being loaded into; there are several ways of doing this, one of the safest is to use the CORS-based encrypted AJAX method described in the USENIX Security paper.

The script is loaded using: <script src=""></script>. The security goal for this script is that the server time will only be released on - trying to load the same script on any other origin must fail, and no other script may be able to tamper the displayed time assuming the alert() function is not tampered (however, other scripts may cause the AJAX call to fail).

It is recommended to use your web console (F12) to track the HTTP requests and scripts loaded from the example.

Registered JavaScript code

Server-side code

Use it on your own website

Step 1: origin registration

You must first register your website. First, generate the private key offline using openssl genrsa -out key.pem 2048. Export the public key using openssl rsa -in key.pem -pubout -out pub.pem. Finally, put the public key on the webserver where you wish to load your defensive script. Enter the URL of the public key below to complete registration of your origin, note that it must include the protocol, domain and port as they would appear in the Origin header. Note that if the origin was already registered it will update the public key.

Step 2: Script registration

Origin: If you want to update a script enter its ID:

DJS Type Inference

Load example:   Category:   File:  
Processing options

Action type:  

Input script:

Source code available here.

Notes: statements all have type undefined. Free variables represent the minimal typing environment in which the input typechecks.
Translation to spi-calculus uses features introduced in version 1.87b of ProVerif and does not cover loops. Library calls should be prefixed by _lib and added to djcl.pvl if required.

Programming Securely with Cryptography Institut National de Recherche en Informatique et Automatique