2sxc turnOn - JS Boot-System for Async and High-Security

Timing and Security... Timing is everything - especially when starting JavaScript. Security is critical - and future sites won't have inline-JS anymore. turnOn solves these two aspects. 

The Future of JS is Async, Defer, SPA and CSP-Secure

JavaScript is changing. Three important trends are emerging that we want to catch before they catch us.

1. Async and Defer are becoming critical to ensure website speed and best UX
2. SPA style systems like Blazor/Oqtane mean the page doesn't reload - so loading JS later on is very difficult
3. Content Security Policies (CSPs) are becoming more widespread - and the crown jewel goes to pages which disable all inline JavaScript

Why Timing is so Hard when Starting JavaScript

In the old days JS was included somewhere in the page and the page stopped processing till this was downloaded and executed. This was bad for performance and UX.

Modern mechanisms use async/defer, but these often cause new problems because often various parts must be ready before anything starts. Ensuring this can be very difficult. In some cases the JS is here before the DOM is, in other cases one of the JS-parts is very late etc.

Why Security is Removing Inline-Scripts

Most XSS-attacks rely on a trick to add just a little bit of inline-JS to the page. That is then used to load more scripts and execute a full attack. Here's an example based on a Boostrap 3 XSS exploit:

1. An attacker knows a website is using Bootstrap3 and discovers a simple tooltip in a gallery which comes from a url-parameter.
2. He then crafts a url where the parameter includes a script-tag which will collect cookies and passwords
3. He then sends this to an admin with a bug report that something is broken
4. The admin clicks on the link, logs on and the attacker now has the password and can continue his attack

To mitigate this, CSP was invented. Part of it ensures that scripts can only be loaded from trusted sources, but if the script manages to be inline (because of an HTML-Editor flaw or a tooltip-flaw) then it would appear to be a trusted source. 

So CSP has an even more secure version: one which disables all inline JS unless it's signed. So the server would have to sign the JS before adding it to the browser. This is hard, and much harder with dynamic scripts which may need a ModuleId or something. 

Enter turnOn

Our new JS library turnOn solves these challenges by placing configurations on the page which are not JS. These configurations are simple HTML attributes like this:

<div turn-on='{ "await": ["window.$"], 
  "run": "window.appContent.maps.load()", 
  "data": "some-google-maps-key" }'>
  <!-- more html -->
</div>

It doesn't matter when turnOn is loaded - once it's loaded it will find these instructions and await scripts to load. Once all of them are available, turnOn will instruct them to start. 

If dynamic content is added to the page (like in a Blazor/Oqtane) scenario, turnOn will detect this and ensure this too is activated, once the dependencies are loaded. 

How this Solves Timing and Security

The timing is pretty obvious - no matter in what order turnOn, dependencies and the DOM are loaded - turnOn will reliably activate the necessary JS once everything is ready. And if advanced checks are necessary you can place these in external files. turnOn will wait for them to load and run these advanced checks as well. 

Security is even more important: There is simply no inline JS to parse or to sign. So if turnOn comes from a trusted source and the JS dependencies come from trusted sources, everything just magically works. No need to sign any inline JS. 

Since turnOn will also pick up parameters from the DOM (like the aforementioned ModuleId) the scripts can started using dynamic configuration and still do the right job. 

Try turnOn Now

You can find the docs here. And you'll need 2sxc 12.02.01 or later for it to be included. Future 2sxc Apps will all use turnOn to work reliably even in ajax refreshes 🚀.

Love from Switzerland,
iJungleboy