Comparação entre as práticas de codificação segura do React e do Angular
30 de outubro de 2019
0 minutos de leituraBoas-vindas ao relatório de 2019 da Snyk sobre o estado da segurança dos frameworks JavaScript. Esta seção aborda a postura geral de segurança dos projetos Angular e React.
Nesta seção, analisamos a postura de segurança dos projetos Angular e React. Isso inclui convenções de codificação segura, recursos de segurança integrados, políticas de divulgação responsável e documentação de segurança específica para cada projeto.
A tabela a seguir apresenta alguns componentes de segurança que consideramos essenciais para a manutenção de boas práticas em qualquer pacote de código aberto e indica como Angular e React lidam com esses componentes — se é que lidam.
Item | Angular | React |
Página de segurança | ✅ https://angular.io/guide/security | ❌O site do React (https://reactjs.org) não menciona nenhuma diretriz de segurança, exceto pela referência à função dangerouslySetInnerHTML na seção DOM Elements da documentação da API Reference. |
Contato de segurança | ✅security@angular.io | ❌Nenhum contato de segurança |
Política de divulgação responsável | ✅Com o respaldo das equipes internas de segurança do Google e baseada na filosofia de segurança da empresa. Referência: https://www.google.com/about/appsecurity/ | ❌Nenhuma política de divulgação responsável |
Exemplos de projetos vulneráveis | ✅https://angular.io/generated/live-examples/security/stackblitz. html | ❌Nenhuma referência a exemplos de projetos vulneráveis |
Sanitização integrada | ✅DomSanitizer oferece uma função integrada de sanitização para valores não confiáveis. Referência: https://angular.io/api/platform-browser/DomSanitizer#sanitize | ❌Cabe aos usuários implementar a sanitização de entradas potencialmente maliciosas usando bibliotecas de terceiros, como DOMPurify. Referência: https://github.com/cure53/DOMPurify |
Política de Segurança de Conteúdo (CSP) | ✅Compatibilidade com CSP para diretivas do Angular v1.x. Referência: https://docs.angularjs.org/api/ng/directive/ngCsp | 🔘Não se aplica ao React |
✅Suporte integrado a CSRF por meio do serviço HttpClient do Angular. Referências: https://angular.io/guide/http e https://docs.angularjs.org/api/ng/service/$http | 🔘Não se aplica ao React como biblioteca de visualização. Cabe aos desenvolvedores lidar com isso usando código personalizado ou módulos da comunidade. |
Práticas de codificação segura do Angular
O Angular v2 e as versões posteriores têm uma arquitetura completamente diferente da do Angular v1, com recursos como a vinculação de dados unidirecional. Além disso, a partir da v2, as versões deixaram de usar a interpolação automática de dados por meio de watchers, bem como outras técnicas que frequentemente causavam muitas das vulnerabilidades de segurança do Angular v1.
A compilação Ahead of Time (AoT) reduz problemas como a injeção de expressões em templates do Angular e permite aplicar segurança durante a compilação, em vez de durante a execução. No entanto, interpolar templates dinamicamente no lado do cliente ainda abre espaço para vulnerabilidades de segurança na forma de injeção de código Angular. Na documentação de boas práticas, o próprio Angular deixa claro que essa interpolação dinâmica não é recomendada. De acordo com a documentação do Angular, ela deve ser evitada, como ressaltam claramente as boas práticas da plataforma.
Para reduzir vulnerabilidades de cross-site scripting, o Angular usa, por padrão, codificação de saída sensível ao contexto ou sanitização de código malicioso. Além disso, as convenções de nomenclatura dos métodos deixam seus possíveis impactos muito mais claros quando o desenvolvedor escolhe usá-los conscientemente, ao contrário do que ocorria nas versões anteriores do Angular, especialmente no Angular v1.x.
Métodos como bypassSecurityTrustHtml(value)ou bypassSecurityTrustUrl() deixam implícitos os riscos de usá-los para inserir dados no DOM. Além disso, o Angular oferece o DomSanitizer integrado para sanitizar valores de forma explícita.
Práticas de codificação segura do React
Por padrão, o React codifica quase todos os valores de dados ao criar elementos DOM. Para permitir que os usuários insiram conteúdo HTML no DOM, o React oferece a função, cujo nome é bastante sugestivo, dangerouslySetInnerHTML(), deixando claro os riscos de usá-la.
Entre os contextos que não são cobertos pelo modelo de segurança do React e ficam a cargo dos usuários estão a criação de:
Elementos âncora (links) HTML cuja entrada fornecida pelo usuário seja usada como valor de origem do atributo href. Isso se aplica principalmente às versões anteriores ao recém-lançado React v16.9, que reduz os riscos de URLs baseadas em javascript: nos valores do atributo href e em outros contextos, como ações de formulários, fontes de iFrames e outros.
Componentes React a partir de entradas fornecidas pelo usuário
A renderização no lado do servidor do React pode introduzir vulnerabilidades de XSS se entradas maliciosas do usuário forem inseridas sem alterações em um contexto JavaScript, sem a codificação ou sanitização adequada.
Segurança HTTP
A partir da versão 1.2, as ramificações de lançamento do Angular v1.x passaram a oferecer suporte de compatibilidade com a Política de Segurança de Conteúdo (CSP), necessária devido ao uso de eval() e do método Function() para interpolar expressões.
A falsificação de solicitação entre sites (CSRF) permite que aplicativos web confiem na origem de uma solicitação. Nas versões mais recentes do Angular, o mecanismo de suporte a CSRF vem integrado ao cliente HTTP por meio do módulo @angular/common/ http. Nas versões Angular v1.x, uma funcionalidade semelhante é oferecida pelo provedor $http.
Ao contrário do Angular, o React não inclui um cliente HTTP e, por isso, não oferece suporte a CSRF pronto para uso. Como o React busca ser uma biblioteca de visualização minimalista, cabe ao desenvolvedor lidar com essa questão usando código personalizado ou módulos mantidos pela comunidade.
Recomendamos fortemente baixar a versão completa do relatório em formato digital. Também disponibilizamos as seguintes seções gerais em posts de blog: