Segurança

Este tópico descreve as proteções integradas do Angular contra vulnerabilidades e ataques comuns em aplicações web, como ataques de cross-site scripting. Ele não cobre segurança no nível da aplicação, como autenticação e autorização.

Para mais informações sobre os ataques e mitigações descritos abaixo, consulte o Open Web Application Security Project (OWASP) Guide.

Boas práticas

Estas são algumas boas práticas para garantir que sua aplicação Angular seja segura.

1. Mantenha-se atualizado com as versões mais recentes das bibliotecas Angular - As bibliotecas Angular recebem atualizações regulares, e essas atualizações podem corrigir defeitos de segurança descobertos em versões anteriores. Verifique o change log do Angular para atualizações relacionadas à segurança.
2. Não altere sua cópia do Angular - Versões privadas e personalizadas do Angular tendem a ficar atrás da versão atual e podem não incluir correções e melhorias de segurança importantes. Em vez disso, compartilhe suas melhorias no Angular com a comunidade e faça um pull request.
3. Evite APIs do Angular marcadas na documentação como "Security Risk" - Para mais informações, consulte a seção Confiando em valores seguros desta página.

Prevenindo cross-site scripting (XSS)

Cross-site scripting (XSS) permite que atacantes injetem código malicioso em páginas web. Esse código pode então, por exemplo, roubar dados de usuário e login, ou executar ações que se passam pelo usuário. Este é um dos ataques mais comuns na web.

Para bloquear ataques XSS, você deve prevenir que código malicioso entre no Document Object Model (DOM). Por exemplo, se atacantes conseguirem enganá-lo para inserir uma tag <script> no DOM, eles podem executar código arbitrário no seu site. O ataque não está limitado a tags <script> — muitos elementos e propriedades no DOM permitem execução de código, por exemplo, <img alt="" onerror="..."> e <a href="javascript:...">. Se dados controlados por atacantes entrarem no DOM, espere vulnerabilidades de segurança.

Modelo de segurança contra cross-site scripting do Angular

Para bloquear sistematicamente bugs de XSS, o Angular trata todos os valores como não confiáveis por padrão. Quando um valor é inserido no DOM a partir de um template binding, ou interpolation, o Angular sanitiza e escapa valores não confiáveis. Se um valor já foi sanitizado fora do Angular e é considerado seguro, comunique isso ao Angular marcando o valor como confiável.

Diferentemente de valores a serem usados para renderização, templates Angular são considerados confiáveis por padrão e devem ser tratados como código executável. Nunca crie templates concatenando entrada do usuário e sintaxe de template. Fazer isso permitiria que atacantes injetem código arbitrário na sua aplicação. Para prevenir essas vulnerabilidades, sempre use o compilador de template Ahead-Of-Time (AOT) padrão em deployments de produção.

Uma camada extra de proteção pode ser fornecida através do uso de Content security policy e Trusted Types. Essas funcionalidades da plataforma web operam no nível do DOM, que é o lugar mais eficaz para prevenir problemas de XSS. Aqui elas não podem ser contornadas usando outras APIs de nível mais baixo. Por essa razão, é fortemente encorajado aproveitar essas funcionalidades. Para fazer isso, configure a content security policy para a aplicação e habilite a imposição de trusted types.

Sanitização e contextos de segurança

Sanitização é a inspeção de um valor não confiável, transformando-o em um valor seguro para inserir no DOM. Em muitos casos, a sanitização não altera um valor de forma alguma. A sanitização depende de um contexto. Por exemplo, um valor que é inofensivo em CSS é potencialmente perigoso em uma URL.

O Angular define os seguintes contextos de segurança:

O Angular sanitiza valores não confiáveis para HTML e URLs. Sanitizar resource URLs não é possível porque elas contêm código arbitrário. Em modo de desenvolvimento, o Angular exibe um aviso no console quando precisa alterar um valor durante a sanitização.

Exemplo de sanitização

O template a seguir faz binding do valor de htmlSnippet. Uma vez interpolando-o no conteúdo de um elemento, e outra fazendo binding na propriedade innerHTML de um elemento:

<h3>Binding innerHTML</h3><p>Bound value:</p><p class="e2e-inner-html-interpolated">{{ htmlSnippet }}</p><p>Result of binding to innerHTML:</p><p class="e2e-inner-html-bound" [innerHTML]="htmlSnippet"></p>

Conteúdo interpolado sempre tem escape — o HTML não é interpretado e o navegador exibe colchetes angulares no conteúdo de texto do elemento.

Para que o HTML seja interpretado, faça binding em uma propriedade HTML como innerHTML. Esteja ciente de que fazer binding de um valor que um atacante possa controlar em innerHTML normalmente causa uma vulnerabilidade XSS. Por exemplo, alguém poderia executar JavaScript da seguinte forma:

import {Component} from '@angular/core';@Component({  selector: 'app-inner-html-binding',  templateUrl: './inner-html-binding.component.html',})export class InnerHtmlBindingComponent {  // For example, a user/attacker-controlled value from a URL.  htmlSnippet = 'Template <script>alert("0wned")</script> <b>Syntax</b>';}

O Angular reconhece o valor como inseguro e automaticamente o sanitiza, o que remove o elemento script mas mantém conteúdo seguro como o elemento <b>.

Uso direto das APIs do DOM e chamadas de sanitização explícitas

A menos que você imponha Trusted Types, as APIs do DOM integradas do navegador não protegem você automaticamente de vulnerabilidades de segurança. Por exemplo, document, o node disponível através de ElementRef, e muitas APIs de terceiros contêm métodos inseguros. Da mesma forma, se você interagir com outras bibliotecas que manipulam o DOM, você provavelmente não terá a mesma sanitização automática que com interpolações do Angular. Evite interagir diretamente com o DOM e use templates Angular sempre que possível.

Para casos onde isso é inevitável, use as funções de sanitização integradas do Angular. Sanitize valores não confiáveis com o método DomSanitizer.sanitize e o SecurityContext apropriado. Essa função também aceita valores que foram marcados como confiáveis usando as funções bypassSecurityTrust, e não os sanitiza, conforme descrito abaixo.

Confiando em valores seguros

Às vezes aplicações genuinamente precisam incluir código executável, exibir um <iframe> de alguma URL, ou construir URLs potencialmente perigosas. Para prevenir sanitização automática nessas situações, diga ao Angular que você inspecionou um valor, verificou como ele foi criado e garantiu que é seguro. Tenha cuidado. Se você confiar em um valor que pode ser malicioso, você está introduzindo uma vulnerabilidade de segurança na sua aplicação. Em caso de dúvida, procure um revisor de segurança profissional.

Para marcar um valor como confiável, injete DomSanitizer e chame um dos seguintes métodos:

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

Lembre-se, se um valor é seguro depende do contexto, então escolha o contexto certo para o uso pretendido do valor. Imagine que o template a seguir precisa fazer binding de uma URL para uma chamada javascript:alert(...):

<h3>Bypass Security Component</h3><h4>An untrusted URL:</h4><p><a class="e2e-dangerous-url" [href]="dangerousUrl">Click me</a></p><h4>A trusted URL:</h4><p><a class="e2e-trusted-url" [href]="trustedUrl">Click me</a></p><h4>Resource URL:</h4><p>Showing: {{ dangerousVideoUrl }}</p><p>Trusted:</p><iframe class="e2e-iframe-trusted-src" width="640" height="390" [src]="videoUrl" title="trusted video url"></iframe><p>Untrusted:</p><iframe class="e2e-iframe-untrusted-src" width="640" height="390" [src]="dangerousVideoUrl" title="unTrusted video url"></iframe>

Normalmente, o Angular sanitiza automaticamente a URL, desabilita o código perigoso e, em modo de desenvolvimento, registra essa ação no console. Para prevenir isso, marque o valor da URL como uma URL confiável usando a chamada bypassSecurityTrustUrl:

import {Component, inject} from '@angular/core';import {DomSanitizer, SafeResourceUrl, SafeUrl} from '@angular/platform-browser';@Component({  selector: 'app-bypass-security',  templateUrl: './bypass-security.component.html',})export class BypassSecurityComponent {  dangerousUrl: string;  trustedUrl: SafeUrl;  dangerousVideoUrl!: string;  videoUrl!: SafeResourceUrl;  private sanitizer = inject(DomSanitizer);  constructor() {    // javascript: URLs are dangerous if attacker controlled.    // Angular sanitizes them in data binding, but you can    // explicitly tell Angular to trust this value:    this.dangerousUrl = 'javascript:alert("Hi there")';    this.trustedUrl = this.sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);    this.updateVideoUrl('PUBnlbjZFAI');  }  updateVideoUrl(id: string) {    // Appending an ID to a YouTube URL is safe.    // Always make sure to construct SafeValue objects as    // close as possible to the input data so    // that it's easier to check if the value is safe.    this.dangerousVideoUrl = 'https://www.youtube.com/embed/' + id;    this.videoUrl = this.sanitizer.bypassSecurityTrustResourceUrl(this.dangerousVideoUrl);  }}

Se você precisar converter entrada do usuário em um valor confiável, use um método do component. O template a seguir permite que usuários insiram um ID de vídeo do YouTube e carreguem o vídeo correspondente em um <iframe>. O atributo <iframe src> é um contexto de segurança de resource URL, porque uma fonte não confiável pode, por exemplo, contrabandear downloads de arquivos que usuários desavisados poderiam executar. Para prevenir isso, chame um método no component para construir uma URL de vídeo confiável, o que faz com que o Angular permita o binding em <iframe src>:

<h3>Bypass Security Component</h3><h4>An untrusted URL:</h4><p><a class="e2e-dangerous-url" [href]="dangerousUrl">Click me</a></p><h4>A trusted URL:</h4><p><a class="e2e-trusted-url" [href]="trustedUrl">Click me</a></p><h4>Resource URL:</h4><p>Showing: {{ dangerousVideoUrl }}</p><p>Trusted:</p><iframe class="e2e-iframe-trusted-src" width="640" height="390" [src]="videoUrl" title="trusted video url"></iframe><p>Untrusted:</p><iframe class="e2e-iframe-untrusted-src" width="640" height="390" [src]="dangerousVideoUrl" title="unTrusted video url"></iframe>

import {Component, inject} from '@angular/core';import {DomSanitizer, SafeResourceUrl, SafeUrl} from '@angular/platform-browser';@Component({  selector: 'app-bypass-security',  templateUrl: './bypass-security.component.html',})export class BypassSecurityComponent {  dangerousUrl: string;  trustedUrl: SafeUrl;  dangerousVideoUrl!: string;  videoUrl!: SafeResourceUrl;  private sanitizer = inject(DomSanitizer);  constructor() {    // javascript: URLs are dangerous if attacker controlled.    // Angular sanitizes them in data binding, but you can    // explicitly tell Angular to trust this value:    this.dangerousUrl = 'javascript:alert("Hi there")';    this.trustedUrl = this.sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);    this.updateVideoUrl('PUBnlbjZFAI');  }  updateVideoUrl(id: string) {    // Appending an ID to a YouTube URL is safe.    // Always make sure to construct SafeValue objects as    // close as possible to the input data so    // that it's easier to check if the value is safe.    this.dangerousVideoUrl = 'https://www.youtube.com/embed/' + id;    this.videoUrl = this.sanitizer.bypassSecurityTrustResourceUrl(this.dangerousVideoUrl);  }}

Content security policy

Content Security Policy (CSP) é uma técnica de defesa em profundidade para prevenir XSS. Para habilitar CSP, configure seu servidor web para retornar um header HTTP Content-Security-Policy apropriado. Leia mais sobre content security policy no guia Web Fundamentals no site Google Developers.

A política mínima necessária para uma nova aplicação Angular é:

default-src 'self'; style-src 'self' 'nonce-randomNonceGoesHere'; script-src 'self' 'nonce-randomNonceGoesHere';

Ao servir sua aplicação Angular, o servidor deve incluir um nonce gerado aleatoriamente no header HTTP para cada requisição. Você deve fornecer esse nonce ao Angular para que o framework possa renderizar elementos <style>. Você pode definir o nonce para o Angular de duas formas:

1. Defina a opção autoCsp como true na configuração do workspace.
2. Defina o atributo ngCspNonce no elemento raiz da aplicação como <app ngCspNonce="randomNonceGoesHere"></app>. Use essa abordagem se você tiver acesso a templating server-side que pode adicionar o nonce tanto ao header quanto ao index.html ao construir a resposta.
3. Forneça o nonce usando o token de injeção CSP_NONCE. Use essa abordagem se você tiver acesso ao nonce em runtime e quiser poder fazer cache do index.html.

import {bootstrapApplication, CSP_NONCE} from '@angular/core';import {AppComponent} from './app/app.component';bootstrapApplication(AppComponent, {  providers: [{    provide: CSP_NONCE,    useValue: globalThis.myRandomNonceValue  }]});

Se você não puder gerar nonces no seu projeto, você pode permitir estilos inline adicionando 'unsafe-inline' à seção style-src do header CSP.

O Angular em si requer apenas essas configurações para funcionar corretamente. À medida que seu projeto cresce, você pode precisar expandir suas configurações de CSP para acomodar funcionalidades extras específicas da sua aplicação.

Impondo Trusted Types

É recomendado que você use Trusted Types como uma forma de ajudar a proteger suas aplicações de ataques de cross-site scripting. Trusted Types é uma funcionalidade da plataforma web que pode ajudá-lo a prevenir ataques de cross-site scripting impondo práticas de codificação mais seguras. Trusted Types também pode ajudar a simplificar a auditoria de código da aplicação.

Para impor Trusted Types para sua aplicação, você deve configurar o servidor web da sua aplicação para emitir headers HTTP com uma das seguintes políticas Angular:

Você deve configurar os headers HTTP para Trusted Types nos seguintes locais:

• Infraestrutura de serving de produção
• Angular CLI (ng serve), usando a propriedade headers no arquivo angular.json, para desenvolvimento local e testes end-to-end
• Karma (ng test), usando a propriedade customHeaders no arquivo karma.config.js, para testes unitários

O seguinte é um exemplo de header especificamente configurado para Trusted Types e Angular:

Content-Security-Policy: trusted-types angular; require-trusted-types-for 'script';

Um exemplo de header especificamente configurado para Trusted Types e aplicações Angular que usam qualquer um dos métodos no DomSanitizer do Angular que contornam segurança:

Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for 'script';

O seguinte é um exemplo de header especificamente configurado para Trusted Types e aplicações Angular usando JIT:

Content-Security-Policy: trusted-types angular angular#unsafe-jit; require-trusted-types-for 'script';

O seguinte é um exemplo de header especificamente configurado para Trusted Types e aplicações Angular que usam lazy loading de modules:

Content-Security-Policy: trusted-types angular angular#bundler; require-trusted-types-for 'script';

Use o compilador de template AOT

O compilador de template AOT previne toda uma classe de vulnerabilidades chamada template injection, e melhora muito o desempenho da aplicação. O compilador de template AOT é o compilador padrão usado por aplicações Angular CLI, e você deve usá-lo em todos os deployments de produção.

Uma alternativa ao compilador AOT é o compilador JIT que compila templates para código de template executável dentro do navegador em runtime. O Angular confia no código de template, então gerar templates dinamicamente e compilá-los, em particular templates contendo dados de usuários, contorna as proteções integradas do Angular. Este é um anti-padrão de segurança. Para informações sobre como construir formulários dinamicamente de forma segura, consulte o guia Dynamic Forms.

Proteção XSS server-side

HTML construído no servidor é vulnerável a ataques de injeção. Injetar código de template em uma aplicação Angular é o mesmo que injetar código executável na aplicação: Isso dá ao atacante controle total sobre a aplicação. Para prevenir isso, use uma linguagem de template que automaticamente escapa valores para prevenir vulnerabilidades XSS no servidor. Não crie templates Angular no lado do servidor usando uma linguagem de template. Isso carrega um alto risco de introduzir vulnerabilidades de template-injection.

Vulnerabilidades em nível HTTP

O Angular tem suporte integrado para ajudar a prevenir duas vulnerabilidades HTTP comuns, cross-site request forgery (CSRF ou XSRF) e cross-site script inclusion (XSSI). Ambas devem ser mitigadas principalmente no lado do servidor, mas o Angular fornece helpers para tornar a integração no lado do cliente mais fácil.

Cross-site request forgery

Em um cross-site request forgery (CSRF ou XSRF), um atacante engana o usuário para visitar uma página web diferente (como evil.com) com código malicioso. Esta página web envia secretamente uma requisição maliciosa para o servidor web da aplicação (como example-bank.com).

Assuma que o usuário está logado na aplicação em example-bank.com. O usuário abre um email e clica em um link para evil.com, que abre em uma nova aba.

A página evil.com imediatamente envia uma requisição maliciosa para example-bank.com. Talvez seja uma requisição para transferir dinheiro da conta do usuário para a conta do atacante. O navegador automaticamente envia os cookies de example-bank.com, incluindo o cookie de autenticação, com essa requisição.

Se o servidor example-bank.com não tiver proteção XSRF, ele não pode distinguir entre uma requisição legítima da aplicação e a requisição forjada de evil.com.

Para prevenir isso, a aplicação deve garantir que uma requisição de usuário se origina da aplicação real, não de um site diferente. O servidor e o cliente devem cooperar para combater esse ataque.

Em uma técnica anti-XSRF comum, o servidor da aplicação envia um token de autenticação criado aleatoriamente em um cookie. O código do cliente lê o cookie e adiciona um header de requisição customizado com o token em todas as requisições seguintes. O servidor compara o valor do cookie recebido com o valor do header da requisição e rejeita a requisição se os valores estiverem faltando ou não corresponderem.

Essa técnica é eficaz porque todos os navegadores implementam a política de mesma origem. Apenas código do site no qual os cookies estão definidos pode ler os cookies desse site e definir headers customizados em requisições para esse site. Isso significa que apenas sua aplicação pode ler esse token de cookie e definir o header customizado. O código malicioso em evil.com não pode.

Segurança XSRF/CSRF do HttpClient

HttpClient suporta um mecanismo comum usado para prevenir ataques XSRF. Ao executar requisições HTTP, um interceptor lê um token de um cookie, por padrão XSRF-TOKEN, e o define como um header HTTP, X-XSRF-TOKEN. Como apenas código que executa no seu domínio poderia ler o cookie, o backend pode ter certeza de que a requisição HTTP veio da sua aplicação cliente e não de um atacante.

Por padrão, um interceptor envia esse header em todas as requisições mutantes (como POST) para URLs relativas, mas não em requisições GET/HEAD ou em requisições com uma URL absoluta.

Para aproveitar isso, seu servidor precisa definir um token em um cookie de sessão legível por JavaScript chamado XSRF-TOKEN no carregamento da página ou na primeira requisição GET. Em requisições subsequentes, o servidor pode verificar que o cookie corresponde ao header HTTP X-XSRF-TOKEN, e portanto ter certeza de que apenas código executando no seu domínio poderia ter enviado a requisição. O token deve ser único para cada usuário e deve ser verificável pelo servidor; isso previne que o cliente crie seus próprios tokens. Defina o token como um digest do cookie de autenticação do seu site com um salt para segurança adicional.

Para prevenir colisões em ambientes onde múltiplas aplicações Angular compartilham o mesmo domínio ou subdomínio, dê a cada aplicação um nome de cookie único.

Configure nomes customizados de cookie/header

Se seu serviço de backend usa nomes diferentes para o cookie ou header do token XSRF, use withXsrfConfiguration para sobrescrever os padrões.

Adicione-o à chamada provideHttpClient da seguinte forma:

export const appConfig: ApplicationConfig = {  providers: [    provideHttpClient(      withXsrfConfiguration({        cookieName: 'CUSTOM_XSRF_TOKEN',        headerName: 'X-Custom-Xsrf-Header',      }),    ),  ]};

Desabilitando proteção XSRF

Se o mecanismo de proteção XSRF integrado não funcionar para sua aplicação, você pode desabilitá-lo usando a feature withNoXsrfProtection:

export const appConfig: ApplicationConfig = {  providers: [    provideHttpClient(      withNoXsrfProtection(),    ),  ]};

Para informações sobre CSRF no Open Web Application Security Project (OWASP), consulte Cross-Site Request Forgery (CSRF) e Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. O paper da Stanford University Robust Defenses for Cross-Site Request Forgery é uma rica fonte de detalhes.

Veja também a palestra de Dave Smith sobre XSRF na AngularConnect 2016.

Cross-site script inclusion (XSSI)

Cross-site script inclusion, também conhecida como vulnerabilidade JSON, pode permitir que o site de um atacante leia dados de uma API JSON. O ataque funciona em navegadores mais antigos substituindo construtores de objetos JavaScript integrados e então incluindo uma URL de API usando uma tag <script>.

Esse ataque só é bem-sucedido se o JSON retornado for executável como JavaScript. Servidores podem prevenir um ataque prefixando todas as respostas JSON para torná-las não executáveis, por convenção, usando a string bem conhecida ")]}',\n".

A biblioteca HttpClient do Angular reconhece essa convenção e automaticamente remove a string ")]}',\n" de todas as respostas antes de processá-las posteriormente.

Para mais informações, consulte a seção XSSI deste post do blog de segurança web do Google.

Auditando aplicações Angular

Aplicações Angular devem seguir os mesmos princípios de segurança que aplicações web regulares e devem ser auditadas como tal. APIs específicas do Angular que devem ser auditadas em uma revisão de segurança, como os métodos bypassSecurityTrust, são marcadas na documentação como sensíveis à segurança.