O JavaScript não é seguro...

Recentemente Douglas Cockford, criador do JSON fez um pronunciamento bem interessante.

A melhor coisa que podemos fazer hoje ao JavaScript é aposentá-lo

Ele segue por uma linha que se encaminha para o lado da evolução da linguagem e como isso ficou complicado devido a como a linguagem está inflando cada vez mais e consequentemente se tornando mais difícil de corrigir em sua base.

É um ponto interessante e com toda certeza muito importante a ser abordado e levado a frente, no entanto, o que me chamou atenção foi outra coisa, uma que estava nos comentários: segurança.

Um contexto geral.

O JavaScript tem um grande objeto global que você provavelmente já usou bastante, o Window. Basicamente, podemos dizer que todo código está rodando no mesmo lugar o tempo inteiro, o que torna esse código vulnerável a qualquer tipo de extensão maliciosa, já que a mesma pode acessar dados sensíveis e alterar comportamentos sem dificuldade, por estar rodando no mesmo lugar.

Esse "recurso" é interessante por permitir coisas que muitas vezes são utilizadas por biblitocas, sendo o exemplo mais famoso o JQuery que insere algumas coisas diretamente no objeto global. Por outro lado, permite que você altere o comportamento padrão de algumas funções nativas do JavaScript e isso pode ser um problema de segurança.

Podemos até mesmo estender esse assunto para a gigante maleabilidade do JS, que também leva a falta de segurança. Isso, todavia, já tem uma solução que é amplamente conhecida e até mesmo utilizada, o TypeScript.

Uma nova linguagem

Segundo o Crockford, temos falhas no JavaScript que não podem ser corrigidas e o inchaço nas funcionalidades saiu de controle já que a linguagem está em constante evolução ao invés de constante melhoria em sua base, o que torna uma melhoria ainda mais complicada.

O pai da extensão do JS, sugere uma nova linguagem chamada E, uma criação conjunta entre o próprio CrockFord e alguns outros integrantes. Este seria uma linguagem orientada a objetos e planejada para tornar a computação mais segura.

Entretanto, sejamos realistas aqui. Essa mudança parece um pouco grande demais para vir assim do nada, principalmente se pensarmos que literalmente todos os navegadores usam o JS para a manipulação da DOM. Mudar isso seria um grande problema e seria uma mudança de longo prazo.

Como o próprio Crockford admitiu, ele nem sequer tem a linguagem pronta ainda e sua concepção é bem complexa e provavelmente vai demorar para termos algo concreto para podermos testar. Além disso, as empresas e desenvolvedores precisariam tomar a iniciativa de começar a aprender a linguagem e implementar ela em suas aplicações, o que me parece uma manobra arriscada visto que a princípio, seria uma linguagem com poucos recursos, bibliotecas e uma comunidade muito pequena.

E então?

Olha, eu concordo que tem muitas coisas contra o JavaScript, porém, ele tem um ponto muito forte e que provavelmente é o que eu mais gosto na linguagem, sua comunidade incrível e extremamente prestativa.

Eu acompanho bastante os grupos da ECMA e um que estou de olho é o TC39, isso por conta de um de seus membros chamado Leo Balter, o qual acompanho desde antes de decidir qual área de programação eu iria seguir.

Entre as propostas do TC39 nós temos Decorators, algumas melhorias para o Locale, melhoras para os arrays e por ai vai. Entre todas essas ideias uma fez meus olhos brilharem ao bater o olho, o ShadowRealm.

ShadowRealm

O que este chuchuzinho aqui faz é basicamente criar um contexto que tem seu próprio objeto global que não a Window, e com isso, funciona sem compartilha recursos de forma global com outras partes da aplicação. É como se separássemos o código do restante.

Usando o exemplo que é proposto dentro da própria publicação do Balter:

const sr = new ShadowRealm();

// Sets a new global within the ShadowRealm only
sr.evaluate('globalThis.x = "my shadowRealm"');

globalThis.x = "root"; //

const srx = sr.evaluate('globalThis.x');

srx; // "my shadowRealm"
x; // "root"

Nesse código, nós criamos a propriedade x tanto dentro quanto fora do ShadowRealm (sr), ambos com valores diferentes, e podemos ver que ambos estão completamente isolados um do outro.

Uma limitação interessante e que é importante ser pontuada é que o SR consegue apenas transportar dados primitivos (String, Number, BigInt, Symbol, Boolean, undefined e null). Outros tipos como objetos ou arrays não são permitidos. Isso é importante quando pensamos em manter a separação total dos ambientes já que objetos e arrays carregam referências do local aonde são criados.

Ainda assim, podemos contornar esse problema com outro recurso muito interessante do ShadowRealm. Ele consegue compartilhar funções e valores retornados por essas funções, como no exemplo abaixo:

const sr = new ShadowRealm();

const wrappedFn = sr.evaluate('(x) =; globalThis.foo = x');

wrappedFn(42);

globalThis.foo; // undefined

sr.evaluate('globalThis.foo'); // 42

Não quero me extender demais nisso então vou deixar aqui o link para o post original dos autores do ShadowRealm. Vale a pena dar uma boa olhada nele e no Github da proposta

No final das contas...

O JavaScript tem seus problemas, isso é fato. É uma linguagem dinâmica até demais muitas vezes e acaba ficando confusa de tantas funções que possui, sendo algumas bem desnecessárias. Não é um exemplo de segurança também.

No entanto, acho improvável que essa linguagem seja simplesmente abandonada agora. É a linguagem mais popular segundo a pesquisa realizada pelo StackOverflow e é extremamente utilizada na Web já que é o padrão para manipular a DOM.

Com isso em mente, é importante olhar para o que temos e tentar trabalhar em cima disso. O ShadowRealm é um exemplo excelente de como a linguagem pode sim melhorar e se tornar muito mais agradável no quesito de segurança.

Além disso, muito do que se trata de segurança parte de nós como os desenvolvedores. Querendo ou não é nossa responsabilidade estudar tanto quanto possível a parte de segurança da informação para saber como lidar com os dados dos nossos usuários.

O código que mandamos para o usuário é código perdido, já está na maquina dele e ele pode fazer o que quiser com isso e ter outra linguagem não muda esse fato. Cabe a você como programador, saber contornar esse problema e controlar o máximo possível o que o usuário vai ter acesso.