Boas práticas de segurança para Angular

Anteriormente, compartilhamos nosso guia Fundamentos de segurança do AngularJS. Desta vez, vamos direto às boas práticas modernas de segurança para Angular. Você pode baixar aqui o guia de boas práticas de segurança para Angular.

6 boas práticas de segurança para Angular

1. O “jeito Angular” protege você contra XSS

2. Use innerHTML com cautela

3. Nunca use templates gerados pela concatenação de entradas do usuário

4. Nunca use APIs nativas do DOM para interagir com elementos HTML

5. Evite mecanismos de templates em templates renderizados no servidor

6. Analise seu projeto Angular em busca de componentes que introduzam vulnerabilidades de segurança

1. O “jeito Angular” protege você contra XSS

Boa prática de segurança para Angular nº 1: use interpolação ({{  }}) para codificar com segurança caracteres potencialmente perigosos e escapar expressões HTML ou CSS não confiáveis em uma expressão de template. 

Assim como React e Vue.js, o Angular adota uma abordagem de segurança por padrão ao lidar com interpolação de strings no navegador. Por padrão, todos os dados são considerados inseguros e não confiáveis. Por isso, essas bibliotecas e outras bibliotecas modernas de interface seguem a boa prática de codificar a saída por padrão para qualquer texto em um contexto HTML.

Como explicamos detalhadamente em nossa publicação anterior sobre boas práticas de segurança para AngularJS, recomendamos fortemente seguir o “jeito Angular” e usar a interpolação de strings integrada com chaves para escapar entradas maliciosas do usuário que possam colocar seu aplicativo web em risco e potencialmente expô-lo a vulnerabilidades de Cross-Site Scripting (XSS).

2. Use innerHTML com cautela

Boa prática de segurança para Angular nº 2: se você precisar adicionar HTML dinamicamente a um componente, vincule sua geração a [innerHTML]. Isso garante que os dados sejam interpretados como HTML no contexto adequado e higienizados, removendo todas as tags inseguras e impedindo a execução de código malicioso de cross-site scripting. Observe que higienizar não é o mesmo que codificar.

Qual é a diferença entre higienização e codificação da saída?

Na codificação da saída, as strings são substituídas por sua representação textual, que pode ser mapeada para determinada tag HTML. Por exemplo, se uma entrada como script for analisada, o Angular pode exibir esse texto codificando os caracteres especiais de ângulo, uma prática padrão em muitas outras bibliotecas e estruturas que implementam boas práticas de segurança. Para isso, ele mapeia a codificação conhecida como entidades HTML e grava no DOM o seguinte texto: script. Em seguida, o navegador interpreta o contexto e exibe uma tag script.

Ao contrário da codificação da saída, a higienização ou filtragem adota uma abordagem mais proativa: detecta caracteres inseguros e os remove do texto que será gravado no DOM.

O contexto é, portanto, um fator decisivo para a codificação da saída e a higienização, pois influencia diretamente a maneira correta de executar cada ação.

Consulte a documentação do Angular para saber mais sobre contextos de segurança. Nas palavras da própria documentação:

O Angular define os seguintes contextos de segurança:

* HTML é usado ao interpretar um valor como HTML, por exemplo, ao vincular a innerHtml.* Style é usado ao vincular CSS à propriedade style.* URL é usado para propriedades de URL, como * Resource URL é uma URL que será carregada e executada como código, por exemplo, em .

Observe o tratamento especial das URLs, que não são filtradas.

3. Nunca use templates gerados pela concatenação de entradas do usuário

Boa prática de segurança para Angular nº 3: nunca concatene entradas potencialmente fornecidas pelo usuário como strings em um template.

Deveria haver pouquíssimos casos de uso — se é que existe algum — que justifiquem concatenar templates em vez de usar corretamente a interpolação de strings ou a composição de componentes recomendada em um aplicativo Angular. Se você encontrar essa má prática em uma base de código, recomendamos higienizar ou refatorar a entrada fornecida na medida do possível.

Veja um exemplo do que você deve observar e evitar:

Boa prática de segurança para Angular: nunca use templates gerados pela concatenação de entradas do usuário

Preste atenção especial à concatenação incomum de string e template na linha 20. O valor de potentialUserInput pode ser uma expressão maliciosa de origem desconhecida ou não confiável. Esse é um exemplo de má prática que você deve identificar.

A seguir, veja um exemplo mais completo que você pode testar no meu playground de Angular. Ele mostra como a entrada do usuário não é tratada com segurança quando é concatenada ao template:

Boa prática de segurança para Angular em ação: nunca use templates gerados pela concatenação de entradas do usuário

Nesse sentido, a recomendação oficial do guia de segurança do Angular diz:

“Nunca gere o código-fonte de templates concatenando entradas do usuário e templates. Para evitar essas vulnerabilidades, use o compilador de templates offline, também conhecido como injeção de template.”

- Guia de segurança do Angular

O Angular recomenda usar seu compilador Ahead of Time para compilar templates offline. Isso ajuda a evitar completamente a grande quantidade de vulnerabilidades de injeção de templates:

ng build --aot
ng serve --aot

Observe que, nas versões mais recentes do Angular — Angular v9 e posteriores —, a compilação com Ivy usa a compilação antecipada por padrão, evitando a injeção de template:

{
  "projects": {
    "my-existing-project": {
      "architect": {
        "build": {
          "options": {
            ...
            "aot": true,
          }
        }
      }
    }
  }
}

4. Nunca use APIs nativas do DOM para interagir com elementos HTML

Boa prática de segurança para Angular nº 4: nunca use APIs nativas do DOM para interagir com elementos HTML na página.

Evite manipular o DOM diretamente. Em vez disso, use os mecanismos de template do Angular e as próprias APIs do Angular para manipular o DOM. Como orientação geral, evite:

•  node.appendChild();

• usar métodos do objeto document para interagir com a página

• usar APIs do jQuery

Existem APIs nativas do Angular que permitem o mesmo tipo de manipulação direta do DOM que recomendamos evitar — por exemplo, a API ElementRef. O ElementRef do Angular pode introduzir problemas de segurança quando usado para acessar um nó diretamente no DOM e manipulá-lo.

Essa e outras interações fora do conjunto de APIs do Angular podem levar a vulnerabilidades de segurança.

5. Evite mecanismos de templates em templates renderizados no servidor

Boa prática de segurança para Angular nº 5: evite mecanismos de templates de terceiros para criar ou adicionar dados a templates em aplicativos Angular renderizados no servidor.

Se você já usou Node.js para criar aplicativos web, provavelmente já trabalhou com algum mecanismo de templates, como EJS, Pug, Handlebars ou uma alternativa. Eles são usados para gerenciar templates renderizados no servidor para a camada de visualização e podem incluir parciais, composições de layout e outros recursos que ajudam a gerar visualizações dinamicamente.

No entanto, implementar esses mecanismos de templates em uma configuração de aplicativo Angular renderizado no servidor pode levar à injeção de código malicioso em um template. Isso acontece porque os dados injetados são externos ao escopo da API do Angular e não podem ser higienizados, apresentando os mesmos riscos da concatenação de strings em templates.

6. Analise seu projeto Angular em busca de componentes que introduzam vulnerabilidades de segurança

Boa prática de segurança para Angular nº 6: sempre analise as dependências de código aberto e os componentes Angular do seu projeto em busca de vulnerabilidades de segurança. Use a plataforma Snyk ou a CLI gratuitamente para encontrar, corrigir e monitorar vulnerabilidades de segurança.

Ao usar bibliotecas de terceiros, como o Angular e seu ecossistema de módulos ou componentes, leve em conta o seguinte: vulnerabilidades de segurança que afetam a biblioteca principal do Angular e vulnerabilidades nos módulos Angular de terceiros que você importa e usa no projeto.

Usar componentes com vulnerabilidades conhecidas é um risco de segurança web documentado no OWASP Top 10, e você deve conhecê-lo. A imagem abaixo mostra uma lista de módulos Angular com vulnerabilidades de segurança conhecidas, por exemplo, aqueles sinalizados ao executar npm install ou npm audit. Como mostra esta imagem do nosso relatório sobre a segurança de frameworks JavaScript, alguns deles têm milhões de downloads por ano e, até hoje, não têm correção de segurança:

Segurança do Angular — o risco das dependências indiretas

Protegendo aplicativos web Angular

Se você usa npm audit, esse é um ótimo primeiro passo. Você já está no caminho certo!

No entanto, mesmo usando o recurso de auditoria do npm, ainda há questões de segurança que você precisa mitigar:

• Talvez você já tenha resolvido todas as vulnerabilidades de segurança do projeto, mas o que acontece quando uma nova vulnerabilidade é descoberta em um desses módulos Angular? Você saberá se ela afeta algum dos seus aplicativos Angular implantados na Vercel, na Netlify ou em outros serviços?

• Outra questão é que o npm audit só rastreia vulnerabilidades conhecidas com um CVE oficial. Já a Snyk rastreia mais de 23 vulnerabilidades de segurança em módulos relacionados ao Angular (https://snyk.io/blog/angular-vs-react-security-bakeoff-2019/), enquanto o npm audit não informa nenhuma delas.

A Snyk resolve esses dois problemas para você — e é grátis ;-)

Como começar?

Crie sua conta gratuita na Snyk e conecte seus projetos de frontend no GitHub ou no Bitbucket. Assim, a Snyk encontra problemas automaticamente e cria pull requests com correções para você.

Outra maneira rápida de começar e encontrar problemas de segurança no Angular é usar a Snyk CLI:

npm install -g snyk
snyk test

A CLI do Snyk oferece mais do que apenas vulnerabilidades CVE conhecidas, ao contrário do npm audit, que não as reporta

Fonte: Angular vs React: disputa de segurança de 2019

A Snyk fornece recomendações práticas de correção para atualizar para uma versão corrigida.

Se você procura algo parecido com um scanner de segurança para Angular, conheça a Snyk para rastrear suas dependências de código aberto, receber notificações e corrigi-las quando vulnerabilidades forem descobertas.

Leituras recomendadas:

• Se você mantém ou desenvolve ativamente com AngularJS, vai achar úteis as 10 boas práticas fundamentais de segurança para AngularJS.

• Como a postura de segurança do Angular se compara à do React? Publicamos um relatório detalhado sobre a segurança de frameworks JavaScript.

O Angular é seguro?

O novo framework Angular (Angular 2 e versões posteriores) é considerado seguro por padrão e não apresenta vulnerabilidades de segurança conhecidas. Em comparação, seu antecessor, o AngularJS, tem mais de 25 vulnerabilidades de segurança conhecidas publicamente, sendo a mais recente de junho de 2020. Siga as boas práticas de segurança para Angular e consulte o relatório da Snyk sobre a segurança de frameworks JavaScript para uma análise aprofundada da segurança do ecossistema de módulos npm para Angular, React e outros projetos.

Como proteger um aplicativo Angular?

Confira algumas diretrizes fundamentais para garantir a segurança de um aplicativo Angular:

1. Como desenvolvedor, siga o “jeito Angular” e suas boas práticas para se proteger contra XSS. Isso significa, por exemplo, não usar innerHTML, nunca usar templates gerados pela concatenação de entradas do usuário e nunca usar APIs nativas do DOM para interagir com elementos HTML.

2. Analise seu projeto Angular em busca de componentes que introduzam vulnerabilidades de segurança. Mesmo que você siga as próprias práticas de segurança do Angular, outros autores de módulos talvez não façam o mesmo, deixando você exposto a problemas graves. Vá além da análise: corrija e monitore possíveis novos problemas. A Snyk é excelente nisso e é uma ferramenta gratuita que você pode conectar facilmente aos seus projetos. Saiba mais sobre boas práticas de segurança para Angular.

O que é mais seguro: Angular ou React?

O projeto Angular (Angular 2+) não tem vulnerabilidades de segurança conhecidas publicamente. O React tem 2 vulnerabilidades de segurança que o afetam, mas elas são antigas, de 2017, e provavelmente você já está usando uma versão mais recente. O antecessor do Angular — o AngularJS — tem mais de 25 vulnerabilidades de segurança. Se você ainda desenvolve ou mantém aplicações com ele, não deixe de analisar seus projetos com uma ferramenta de segurança gratuita e voltada para desenvolvedores, como o Snyk. Sobre esse tema, você pode ler o relatório sobre a segurança de frameworks JavaScript, que investiga o estado da segurança nos ecossistemas Angular e React.

O Angular higieniza as entradas?

Por padrão, o Angular codifica a saída de todo texto potencialmente perigoso que possa levar a um ataque XSS, desde que você siga as práticas recomendadas de codificação segura do Angular, como usar chaves duplas ({{}}) para interpolação segura. Se, no entanto, você usar o binding innerHTML do Angular, ele fará o possível para proteger você, higienizando o conteúdo perigoso. Ainda assim, essa deve ser sua última opção para adicionar entradas do usuário.