FlawOpen

flawopen.com/Segurança do Angular/Angular

Proteção XSS do Angular: padrões seguros e APIs de bypass

Página de referência
Resposta curta

O Angular trata como não confiáveis os valores em bindings de template: a interpolação escapa texto, enquanto bindings de HTML e URL usam sanitização contextual. A fronteira perigosa é a confiança explícita: bypassSecurityTrust* instrui o Angular a ignorar a sanitização normal daquele valor. Use-o somente após validar e construir o valor para o contexto de segurança exato em que será usado.

RISKY — the escape hatch
this.safeHtml = this.sanitizer
  .bypassSecurityTrustHtml(comment);
// <div [innerHTML]="safeHtml"></div>
MAIS SEGURO — mantenha entrada não confiável como texto
<div>{{ comment }}</div>
// a interpolação escapa a marcação como texto

O que o Angular sanitiza — e o que não pode

O Angular escapa texto interpolado e sanitiza valores não confiáveis nos contextos HTML e URL. Por exemplo, [innerHTML] remove marcação perigosa e preserva HTML seguro; a interpolação comum nem sequer interpreta a marcação. Uma URL de recurso (como a origem de um iframe que carrega conteúdo executável) não pode ser sanitizada genericamente, pois pode identificar código arbitrário. Nunca passe valores controlados por atacantes a bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl ou APIs de bypass relacionadas: elas declaram que o valor é seguro para um contexto específico e ignoram a sanitização. Para uma incorporação legítima, construa a URL a partir de uma origem fixa e um identificador validado imediatamente antes de marcá-la como confiável.

Audite APIs de bypass e sinks do DOM

grep -rn "bypassSecurityTrust" --include="*.ts" .

Perguntas frequentes

Defesa em profundidade com CSP e Trusted Types

Use Content Security Policy (CSP) e imponha Trusted Types como defesa em profundidade junto com os bindings seguros do Angular. O Angular exige a política Trusted Types angular#unsafe-bypass quando a aplicação chama DomSanitizer.bypassSecurityTrust*. Prefira remover essas chamadas; se alguma for necessária, inventarie cada ponto de chamada e confie apenas em valores validados para o contexto exato.

O Angular sanitiza todas as formas de escrever no DOM?

Não. Bindings de template do Angular recebem proteções do framework, mas APIs diretas do DOM, ElementRef e bibliotecas DOM de terceiros podem contorná-las. Prefira bindings de template, audite esses sinks separadamente e não marque uma entrada como confiável sem validá-la para o contexto de segurança exato.

Referências

Veja também Cross-Site Scripting (XSS, CWE-79): como funciona e como evitar em todas as linguagens — flawopen.com XSS por MIME sniffing: Content-Type e nosniff CSP e escape de saída: você precisa dos dois? dangerouslySetInnerHTML do React é seguro? DOMPurify basta para proteger innerHTML? Markdown é seguro contra XSS? Svelte é seguro contra XSS por padrão?