Skip to main content

Comparativo lado a lado das vulnerabilidades de segurança do Angular e do React em 2019

Escrito por
JavaScript Report feature

30 de outubro de 2019

0 minutos de leitura

Boas-vindas ao relatório State of JavaScript Frameworks Security 2019 da Snyk.

Nesta seção, analisamos o impacto das vulnerabilidades de segurança, observando a gravidade, as pontuações CVSS e outros dados ao longo dos anos para Angular e React. Além disso, examinamos quanto tempo leva para corrigir e lançar correções para as vulnerabilidades de cada framework e como isso evoluiu ao longo dos anos.

Baixe o relatório aqui!

Angular vs. React: comparando a gravidade das vulnerabilidades

Podemos entender melhor os riscos gerais causados pelos problemas de segurança encontrados em projetos de frontend baseados em React e Angular ao analisar as pontuações de gravidade.

O que é CVSS?

Para isso, vale revisar brevemente o sistema de pontuação CVSS. Assim como bugs comuns no código-fonte são classificados por gravidade, por exemplo, alta ou média, os bugs de segurança — que chamamos de vulnerabilidades de segurança — também recebem uma classificação que ajuda a determinar o risco potencial para uma organização.

As vulnerabilidades de segurança recebem uma classificação de gravidade pelo Common Vulnerability Scoring System (CVSS), adotado pela organização FIRST como padrão de fato e amplamente usado para pontuar vulnerabilidades e exposições comuns, conhecidas como CVEs.

Para facilitar a comparação entre vulnerabilidades, o CVSS converte as pontuações numéricas em faixas e associa cada uma a um nível de gravidade.

Uma explicação detalhada sobre o CVSS e seus desafios está disponível em https://snyk.io/blog/scoring-security-vulnerabilities-101-introducing-cvss-for-cve/

Ao longo do relatório, usamos as pontuações CVSS v2, apresentadas na tabela a seguir:

Gravidade

Pontuação

0.1 - 3.9

baixa

4.0 - 6.9

média

7.0 - 10.00

alta

Angular e React: resultados do CVSS

Poucas vulnerabilidades foram encontradas nos pacotes principais do React. Todas são vulnerabilidades de Cross-Site Scripting, divulgadas regularmente a cada dois anos. As pontuações CVSS variam de 6,5 a 7,1 — ou seja, todas têm gravidade média a alta.

O gráfico a seguir mostra a gravidade das vulnerabilidades no projeto principal do React ao longo do tempo:

Linha do tempo que mostra vulnerabilidades no projeto principal do React: XSS com pontuação 7,1 em dezembro de 2013, seguido por divulgações de XSS com pontuação 6,5 em março de 2015 e agosto de 2018.

Ao analisar as vulnerabilidades de segurança do Angular v1.x, vemos que o Angular v1.5 tem o maior número: sete no total — três de gravidade alta e quatro média. Felizmente, conforme as versões evoluem, o número e a gravidade das vulnerabilidades diminuem. Em 2019, ainda não havia sido divulgada nenhuma nova vulnerabilidade em qualquer versão do Angular!

O gráfico a seguir mostra o número de vulnerabilidades do Angular v1.x por ano e nível de gravidade:

Gráfico de barras que mostra as vulnerabilidades do Angular V1.x por ano e gravidade de 2013 a 2018; as vulnerabilidades de gravidade média atingiram o pico de quatro em 2015.

A variedade de tipos de vulnerabilidade divulgados em todas as versões do Angular 1.x não é motivo de grande preocupação. Os riscos de segurança se manifestam em outros aspectos. O mais notável é a gravidade do tipo de vulnerabilidade mais comum, divulgado repetidamente em diferentes versões. Na verdade, vulnerabilidades de Cross-Site Scripting (XSS) são uma grande preocupação de segurança em todo o universo de frontend. E com o Angular não é diferente. Os dados que encontramos refletem isso: há dez vulnerabilidades de XSS no total nas versões do Angular 1.x.

Gráfico de barras que mostra as vulnerabilidades do Angular 1.x por tipo, com destaque para Cross-site Scripting (XSS), com 10, e duas categorias com 2 cada.

Tempo para corrigir e para lançar a correção

Um fator importante para avaliar a postura de segurança de projetos de código aberto é a rapidez com que mantenedores e colaboradores respondem às vulnerabilidades com correções e publicam versões para os usuários. Analisamos essas métricas nos projetos principais do Angular e do React, acompanhando o histórico de vulnerabilidades conhecidas já corrigidas em cada um deles.

No caso do Angular v1.x, o gráfico a seguir está organizado em ordem cronológica, começando em junho de 2013, quando surgiu a primeira vulnerabilidade do AngularJS, e indo até junho de 2018. Ele mostra quantos dias foram necessários para corrigir uma vulnerabilidade, desde sua comunicação pública ao projeto até o lançamento de uma versão com a correção, disponível para atualização pelos usuários. Um tempo curto para corrigir indica que a equipe de desenvolvimento respondeu rapidamente ao relato de segurança; um tempo curto para lançar a correção mostra que a equipe conseguiu disponibilizar rapidamente uma versão oficial para atualização.

Gráfico de linhas que mostra o tempo médio, em dias, para lançar e corrigir por ano, de 2013 a 2018.

Como podemos ver, a primeira vulnerabilidade relatada no Angular foi corrigida no repositório de código em apenas um dia, mas levou 74 dias para que a correção fosse publicada em uma versão oficial que os usuários pudessem instalar.

Nas versões do Angular v1.x, o tempo médio para corrigir uma vulnerabilidade de segurança foi de 7,47 dias, e o tempo médio para publicar uma versão com a correção foi de 20,5 dias.

Uma exceção nos dados da página anterior é uma vulnerabilidade de ataque de callback JSONP, que levou 570 dias para ser corrigida de fato e mais 64 dias entre a inclusão da correção no repositório de código-fonte e seu lançamento oficial.

O React tem bem menos vulnerabilidades: apenas três afetam o projeto principal. Duas das três foram relatadas e tratadas internamente pela equipe do React; por isso, o tempo para corrigi-las aparece como zero dia, e a publicação de uma versão oficial levou apenas um dia. A terceira é uma vulnerabilidade de Cross-Site Scripting, presente desde o React v0.4 e v0.5. Foram necessários 176 dias para corrigi-la, seguidos por um atraso de 27 dias até o lançamento da correção de segurança.


Recomendamos muito baixar a versão completa do relatório em formato digital. Também disponibilizamos as seguintes seções gerais em formato de post de blog: