6 práticas recomendadas de segurança do Angular para equipes de desenvolvimento em 2026

Principais conclusões

• O Angular escapa o conteúdo interpolado, sanitiza valores HTML e URLs não confiáveis nas ligações de modelos e lida com a parte do cliente da proteção contra CSRF por padrão, mas a proteção total depende de seu servidor emitir e validar o token.
• XSS, CSRF, falhas de autorização e dependências sem patch são os riscos que mais frequentemente afetam as aplicações Angular, e a maioria deles surge fora das proteções padrão do framework.
• A Política de Segurança de Conteúdo (CSP), os Tipos Confiáveis e a Integridade de Subrecursos em scripts de terceiros abrangem superfícies de ataque sobre as quais o Angular não tem visibilidade.
• As versões 19 e anteriores do Angular já estão fora de suporte e não recebem mais correções de segurança oficiais; as equipes que ainda não puderam migrar precisam de um plano para continuar protegidas.

 

Aplicativos Angular raramente são comprometidas devido a uma vulnerabilidade na própria estrutura. Elas são comprometidas porque um desenvolvedor utilizou bypassSecurityTrustHtml para fazer com que um widget de terceiros fosse renderizado corretamente e desativou a proteção contra XSS do Angular para esse valor. Ou porque o backend nunca validou um token XSRF. Ou porque uma dependência três níveis abaixo ficou dois anos sem receber uma correção. Esse é o padrão por trás da maioria dos problemas de segurança do Angular: o framework é sólido; as soluções alternativas e a configuração ao redor, não.

Este guia aborda as práticas de segurança do Angular que preenchem a lacuna entre o que o framework protege automaticamente e o que sua equipe precisa implementar manualmente.

Como o Angular lida com a segurança

 

Antes de proteger um aplicativo Angular, é bom saber o que o Angular já faz por você. Acontece que são muitas coisas.

Por padrão, o Angular trata todos os valores como não confiáveis. Quando um valor é inserido no DOM por meio de interpolação ou de uma ligação de modelo, o Angular aplica caracteres de escape ou o sanitiza. O conteúdo interpolado sempre recebe caracteres de escape, portanto {{ }} exibe a marcação como texto visível, em vez de analisá-la. As ligações de propriedades passam por uma sanitização sensível ao contexto, e as regras dependem desse contexto. O Angular define quatro contextos de segurança – HTML, estilo, URL e URL de recurso – e sanitiza valores HTML e de URL não confiáveis. URLs de recurso não podem ser sanitizadas, pois, por definição, elas carregam e executam código; portanto, o Angular se recusa a vinculá-las, a menos que você as marque explicitamente como confiáveis. Esse comportamento bloqueia a maioria das tentativas diretas de XSS.

O Angular também compila os modelos antecipadamente por padrão em aplicativos CLI, o que elimina a classe de bugs relacionada à injeção de modelos, e seu HttpClient vem com gerenciamento de tokens XSRF no lado do cliente e remoção automática de prefixos de resposta XSSI.

Essas proteções só funcionam enquanto você permanecer dentro delas. Escreva diretamente no DOM por meio de ElementRef, passe um valor não validado para uma ligação ou permita que seu servidor ignore a validação XSRF, e as garantias deixam de valer. As seções a seguir tratam das lacunas que o Angular não preenche automaticamente.

Análise da realidade: “O Angular é seguro por padrão” é uma afirmação parcialmente verdadeira. O Angular escapa e sanitiza a saída dos modelos e oferece auxiliares do lado do cliente para CSRF e XSSI, mas não faz nada em relação a tokens vazados, pacotes npm vulneráveis, autenticação fraca ou uma versão em fim de vida exposta a vulnerabilidades (CVEs) públicas. O framework protege partes específicas da renderização do lado do cliente e das camadas HTTP, não toda a sua aplicação.

Vulnerabilidades comuns de segurança no Angular

Eis a verdade incômoda: a maioria das vulnerabilidades em aplicativos Angular não são falhas do próprio Angular. São pontos em que um desenvolvedor saiu das proteções do framework, geralmente para lançar um recurso mais rapidamente, sem implementar uma proteção equivalente.

Vulnerabilidade	Como isso ocorre no Angular	O que o Angular abrange e o que não abrange
XSS	Dados não confiáveis marcados como seguros com bypassSecurityTrust*, ou gravados diretamente no DOM por meio de ElementRef ou element.innerHTML	A sanitização contextual se aplica às ligações de modelos, e não às gravações diretas no DOM
CSRF	O servidor nunca define nem valida o token XSRF	HttpClient envia o token; o servidor deve emiti-lo e verificá-lo
Dependências vulneráveis	Pacotes npm desatualizados ou uma versão do Angular em fim de vida útil	As correções do upstream são descontinuadas ao final do ciclo de vida
Controle de acesso com falha	Autorização do lado do servidor ausente ou inconsistente; guardas de rota ausentes ou mal configurados	As proteções do lado do cliente não podem impor o controle de acesso do lado do servidor
Injeção de scripts de terceiros	Scripts externos carregados sem controles SRI ou CSP	O Angular não isola o código de terceiros em uma sandbox

Cross-Site Scripting (XSS)

O XSS é a vulnerabilidade que o modelo de segurança do Angular foi projetado de forma mais explícita para prevenir. Todo o sistema de sanitização existe porque a injeção de conteúdo não confiável no DOM é explorada com tanta frequência — e isso também faz com que a sanitização do Angular seja a proteção que os desenvolvedores mais frequentemente desativam acidentalmente quando buscam uma maneira de contornar a restrição.

O Relatório de 2024 da Synopsys sobre Segurança e Análise de Riscos de Código Aberto, que analisou mais de 1.000 bases de código comerciais, constatou que oito das dez principais vulnerabilidades de código aberto se enquadravam na CWE-707, a ampla classe de “neutralização inadequada” que abrange falhas decorrentes do tratamento inseguro de entradas não confiáveis, incluindo cross-site scripting. O tratamento inadequado de entradas não é um caso isolado; é uma das fontes mais confiáveis de vulnerabilidades graves em todo o ecossistema de código aberto.

Em aplicativos Angular, o XSS geralmente se deve a uma dessas três causas: um chamada ao método DomSanitizer.bypassSecurityTrustHtml() em dados que um invasor pode manipular, conteúdo que foi incorretamente marcado como confiável em algum ponto anterior, ou código que grava diretamente no DOM por meio de ElementRef, APIs nativas do navegador ou uma biblioteca de terceiros que opera fora do controle do Angular. Um [innerHTML] simples, por outro lado, é sanitizada.

A solução não é complicada. Não passe dados não confiáveis por um bypass e, nos casos em que for realmente necessário renderizar HTML fornecido externamente, limpe-o com um sanitizador bem mantido antes que ele chegue ao modelo. Trate cada chamada de bypassSecurityTrust* em sua base de código como uma descoberta que merece uma análise mais detalhada.

Cuidado: Todo método bypassSecurityTrust* faz exatamente o que o nome indica: desativa a sanitização do Angular para aquele valor. O `DomSanitizer.sanitize()` não limpará um valor que já tenha sido marcado como confiável; portanto, envolver um `bypass` em uma chamada de `sanitize` não traz nenhum benefício. Basta um desses em um campo ao qual um invasor tenha acesso para criar uma vulnerabilidade de XSS armazenado. Procure por eles antes de cada lançamento.

Falsificação de Solicitação entre Sites (CSRF)

O CSRF no Angular geralmente é uma falha de configuração, e não um bug no código. Por padrão, o HttpClient lê o XSRF-TOKEN e o reenvia como um X-XSRF-TOKEN em solicitações que alteram o conteúdo de URLs relativas e de mesma origem. Ele não adiciona o cabeçalho a GET ou HEAD , que não precisam dele, nem a solicitações entre origens. O tratamento do lado do cliente é feito.

O problema está na outra metade. O Angular não pode definir esse cookie nem validar o token retornado para você. Se o seu backend nunca emitir o cookie ou aceitar solicitações sem esse cabeçalho, a proteção é meramente cosmética. A própria documentação do Angular é bem direta a esse respeito: a falha na configuração do servidor torna a proteção padrão ineficaz. Esse é um dos problemas mais comuns em aplicativos de página única — o front-end parece protegido, enquanto o servidor não está realizando a verificação.

Dependências vulneráveis e desatualizadas

Essa é a maior área oculta e aquela que as equipes demoram mais tempo a perceber. O código do seu aplicativo pode estar bem organizado, mas seus node_modules não é sua, e grande parte do que vai parar nela chega por meio de dependências indiretas e transitivas que ninguém da sua equipe escolheu.

O Relatório de 2026 da Black Duck sobre Segurança e Análise de Riscos de Código Aberto, que auditou 947 bases de código comerciais em 17 setores, quantifica o que a maioria das equipes já intui, mas raramente toma medidas a respeito. Entre essas bases de código, 93% continham componentes sem atividade de desenvolvimento há pelo menos dois anos, 92% tinham componentes executando versões 10 ou mais atrás das versões atuais e apenas 7% dos componentes estavam na versão mais recente disponível. A média de vulnerabilidades por base de código mais que dobrou em relação ao ano anterior, chegando a 581. As descobertas relacionadas ao jQuery são particularmente reveladoras: quatro das dez CVEs mais comuns nas bases de código auditadas eram vulnerabilidades do jQuery corrigidas há anos, e entre 25% e 28% das bases de código ainda apresentavam pelo menos uma delas.

Há dois relógios em funcionamento. O primeiro é a sua árvore de dependências do npm, que acumula CVEs independentemente de você mexer nela ou não. O segundo é o próprio Angular.

O Angular alterou sua cadência de lançamento a partir da versão 22. As versões principais agora são lançadas anualmente e têm normalmente recebem suporte por 24 meses: 12 meses de suporte ativo, seguidos por 12 meses de LTS, durante os quais são disponibilizadas apenas correções críticas e patches de segurança. Todas as versões até a versão 21, inclusive, seguiam a cadência anterior de seis meses e um período de 18 meses – 6 meses de suporte ativo, seguidos por 12 meses de LTS. De qualquer forma, o suporte chega ao fim.

Versão do Angular	Situação (agosto de 2026)	O suporte ativo chega ao fim	Fim do suporte de segurança (LTS)
22	Ativo	Junho de 2027	Junho de 2028
21	LTS	Encerrado em 3 de junho de 2026	Junho de 2027
20	LTS	Encerrado em 19 de novembro de 2025	28 de novembro de 2026
19 anos ou menos	Fim da vida	–	Não há patches oficiais

As datas seguem o cronograma de suporte publicado pelo Angular, que a equipe oferece como orientação aproximada e pode ser revisado.

Quando você estiver usando uma versão em fim de vida (EOL), ela não será mais elegível para correções de segurança de rotina do upstream; portanto, qualquer novo CVE que afete a estrutura ou sua árvore de código permanecerá sem correção, a menos que você faça a atualização ou contrate o suporte do fornecedor. Voltaremos a abordar o que fazer a respeito disso.

Melhores práticas de segurança do Angular para equipes de desenvolvimento

1. Confie no desinfetante, pare de ignorá-lo

O hábito mais importante é manter a sanitização do Angular ativada. Use por padrão a interpolação e a vinculação de propriedades, que realizam o escape e a sanitização automaticamente. Um elemento [innerHTML] é sanitizada, portanto, por si só, não é insegura — mas use-a apenas quando realmente precisar renderizar marcação HTML e nunca a combine com conteúdo controlado por invasores e um bypass.

Caso você realmente precise renderizar HTML fornecido externamente, limpe-o com um sanitizador de HTML bem mantido e adequado ao seu modelo de ameaças, e lembre-se de que DomSanitizer.sanitize() não limpará um valor já envolvido por um bypassSecurityTrust* . Torne as chamadas de bypass passíveis de revisão: uma regra de lint ou um grep de CI que sinalize cada uma delas obriga uma pessoa a justificá-la. Se uma auditoria de segurança encontrar um bypass em dados acessíveis a invasores, trate isso como um impedimento ao lançamento, não como um item em atraso.

Dica profissional: Procure em seu código por bypassSecurityTrust antes de cada lançamento importante. Se você encontrar uma e não conseguir explicar em uma frase por que esse valor específico é seguro, provavelmente ele não é.

 2. Adicione uma Política de Segurança de Conteúdo (CSP)

Uma Política de Segurança de Conteúdo (CSP) é sua segunda linha de defesa contra ataques XSS que conseguem passar pela sanitização. A CSP restringe quais origens e padrões de execução o navegador permitirá, de modo que scripts injetados que não atendam à política não serão executados. O grau de bloqueio efetivo depende da política que você definir: origens amplas, “unsafe-inline”ou padrões permissivos de carregamento de scripts permitirão a passagem de muitos elementos.

O Angular documenta uma política mínima para um novo aplicativo:

Content-Security-Policy: default-src ‘self’; style-src ‘self’ ‘nonce-randomNonceGoesHere’;     script-src ‘self’ ‘nonce-randomNonceGoesHere’;

 The nonce matters. Angular inserts <style> elements at runtime, and a strict policy without a nonce will block them and break your styling. Generate a fresh, unpredictable nonce for every response and hand it to Angular in one of three supported ways: set autoCsp to true in your workspace configuration, set the ngCspNonce attribute on the root application element, or provide it through the CSP_NONCE injection token. Serve the policy as a response header from your web server or CDN, not as a meta tag. If your HTML is cached at a CDN, generate the nonce at the edge – a nonce baked into a cached response is the same value for every visitor, which defeats the point.

Combine o CSP com o Trusted Types. O Angular recomenda fortemente a execução de ambos, pois eles operam no nível do DOM, onde não podem ser contornados por meio de APIs de navegador de nível inferior. Aplicativos que chamam qualquer bypassSecurityTrust* precisam do política angular#unsafe-bypass , e aplicativos com chunks carregados de forma preguiçosa precisam do angular#bundler.

Dica profissional: Implemente o CSP primeiro no modo “somente relatório” com Content-Security-Policy-Report-Only. Você receberá relatórios de violação sem prejudicar o funcionamento do aplicativo, o que permite identificar todos os scripts embutidos, estilos injetados e origens de terceiros antes de aplicar a política. Equipes que pulam essa etapa quase sempre causam algum problema na produção.

 3. Configurar a proteção contra XSRF/CSRF de ponta a ponta

Não pense que o tratamento do XSRF no lado do cliente pelo Angular é tudo. Ele envia o token; cabe ao seu servidor emiti-lo e verificá-lo.

API de mesma origem: confirme se o backend define o XSRF-TOKEN por sessão em um cookie legível por JavaScript e rejeita qualquer solicitação válida cujo cabeçalho esteja ausente ou não corresponda. Se o seu backend usar nomes diferentes, configure-os com withXsrfConfiguration() em vez de desativar o interceptador.

API entre origens: O Angular não anexa o cabeçalho às solicitações entre origens, portanto, o esquema padrão baseado em cookies não se aplica. Projete a proteção de forma deliberada em ambas as extremidades: atributos de cookies, gerenciamento de credenciais, uma lista explícita de origens confiáveis em sua configuração CORS e validação de token ou origem no lado do servidor. O CORS, por si só, não é uma defesa contra CSRF.

Vale a pena, de fato, realizar um teste de penetração nessa rota. Os scanners da Web detectam as falhas óbvias de CSRF, mas é fácil que o cookie esteja configurado corretamente enquanto a validação é silenciosamente ignorada em um subconjunto de rotas.

4. Proteção de rotas e autorização

O roteador do Angular é poderoso, e é justamente por isso que os erros de autorização nesse contexto têm um custo tão alto — embora nem sempre da maneira que as equipes imaginam. O Angular não impõe o controle de acesso; isso fica a cargo de você e do seu backend.

A ausência de uma proteção expõe as visualizações do lado do cliente e os caminhos de navegação a qualquer pessoa que conheça a URL. Isso se torna uma violação de dados quando a API por trás dessas visualizações também deixa de verificar a autorização. Ambos os aspectos são importantes, e apenas um deles é de responsabilidade do Angular.

Algumas coisas que é preciso acertar:

• Toda rota protegida precisa de um guard, e não confie no fato de a interface do usuário ocultar links para seções não autorizadas. O Angular moderno utiliza guards funcionais – CanActivateFn para navegação e canMatch para correspondência de rotas – em vez das interfaces baseadas em classes, que estão obsoletas.
• Os guardas podem consultar o estado de autenticação ou permissão derivado do servidor, mas nunca devem substituir as verificações de autorização na API. Um sinalizador em localStorage que qualquer usuário possa editar não constitui um controle de acesso.
• Use canMatch em rotas carregadas de forma preguiçosa para que o roteador não corresponda nem carregue a configuração da rota para usuários não autorizados.
• Teste as condições de proteção explicitamente. É comum ter uma condição de proteção que retorne true em casos extremos, quando não deveria.

Atenção: O carregamento diferido não garante privacidade. Os Route Guards são executados no navegador e controlam a navegação; eles não impedem que ninguém acesse diretamente um pacote de JavaScript disponibilizado publicamente ou o leia no DevTools. Nunca coloque segredos, endpoints não divulgados ou lógica de autorização confidencial no código do lado do cliente, seja ele carregado diferidamente ou não, e imponha a autorização em todas as solicitações protegidas do backend.

 5. Tratar os scripts de terceiros como uma superfície de ameaça

Cada script de terceiros que você carrega — ferramentas de análise, widgets de chat, ferramentas de teste A/B, redes de publicidade — é executado com os mesmos privilégios que o seu próprio código. A sanitização do Angular protege seus modelos, mas não isola em sandbox os scripts carregados fora deles.

Essa é uma questão prática, não teórica. Em setembro de 2025, um ataque de phishing à conta de um único mantenedor do npm injetou código malicioso em 18 pacotes amplamente utilizados, incluindo chalk e debug, que, juntos, somam bilhões de downloads semanais. Dias depois, o worm Shai-Hulud, capaz de se auto-replicar, coletou credenciais de desenvolvedores e se espalhou pelo registro; o GitHub removeu mais de 500 pacotes comprometidos e a CISA emitiu um alerta. O OSSRA de 2026 dá forma a esse padrão: dos pacotes maliciosos identificados pela Black Duck nos ecossistemas de código aberto, 66% foram criados especificamente para causar danos por meio de táticas como typosquatting e confusão de dependências, enquanto 34% eram pacotes legítimos sequestrados após terem conquistado a confiança da comunidade.

Algumas medidas que vale a pena implementar:

1. A Integridade de Subrecursos (SRI) utiliza hashes em scripts hospedados externamente com conteúdo estável e versionado. Se o arquivo obtido não corresponder mais ao hash declarado, o navegador se recusa a executá-lo. A SRI também requer a configuração adequada de CORS no servidor para funcionar.
2.  Regras do CSP que permitem explicitamente origens de terceiros, em vez de permitir * ou ‘unsafe-inline’.
3. Auditorias regulares para verificar quais scripts de terceiros são carregados no ambiente de produção. As ferramentas de marketing e análise se acumulam ao longo do tempo e, muitas vezes, trazem consigo suas próprias subdependências.
4. Cópias hospedadas internamente e fixadas de bibliotecas de terceiros, sempre que possível. Isso remove a CDN da sua cadeia de confiança, mas também transfere a responsabilidade pelas atualizações para a sua equipe; portanto, combine essa prática com um processo para acompanhar as correções do desenvolvedor original.

6. Mantenha o Angular e suas dependências atualizados

A aplicação de patches é uma prática que as equipes tendem a adiar até que se torne uma migração. Execute o npm audit na CI e analise de fato o que for encontrado, em vez de desconsiderar os avisos só porque não há uma solução imediata. Trate isso como uma contribuição, e não como uma avaliação completa: ele relata alertas conhecidos sobre os pacotes declarados em seus manifestos e arquivos de bloqueio, e o OSSRA de 2026 constatou que 17% dos componentes de código aberto entram nas bases de código fora dos gerenciadores de pacotes padrão — trechos copiados e colados, código de fornecedores, código gerado por IA —, onde os scanners baseados em manifestos nunca os detectam.

O mesmo relatório cita uma pesquisa separada da Black Duck de 2025, na qual 65% das organizações que responderam afirmaram ter sofrido um ataque à cadeia de suprimentos de software no ano anterior. Vale a pena refletir sobre esse número: os ataques à cadeia de suprimentos não são mais um risco marginal, mas sim um problema comum nas empresas. Entre as bases de código auditadas, 87% continham pelo menos uma vulnerabilidade conhecida de código aberto e 78% continham pelo menos uma vulnerabilidade de alto risco.

npm audit   Atualização do ng @angular/core @angular/cli

 Mantenha o Angular dentro da janela de versões suportadas, automatize os PRs de dependências com o Dependabot ou o Renovate e leve a sério as CVEs transitivas, mesmo quando não houver uma correção direta disponível. Uma vulnerabilidade pode continuar sendo explorável várias camadas abaixo na árvore de dependências; portanto, avalie se sua aplicação realmente acessa o código vulnerável, em vez de descartá-la por ser indireta.

A versão mais complexa desse problema é o que acontece quando não é possível fazer a atualização. Uma migração para uma versão principal pode ser cara, o aplicativo está estável e é difícil justificar economicamente uma reescrita. É aí que surge a lacuna do EOL.

Ferramentas e soluções para segurança no Angular

A segurança do Angular não se resume a uma implementação única. Trata-se de uma atividade contínua que envolve a aplicação de patches, o monitoramento de vulnerabilidades e a cobertura de suporte. A maioria das equipes precisa de mais de uma ferramenta para dar conta disso.

Solução	O que está coberto	Ideal para
Snyk / Dependabot / auditoria do npm	Alertas conhecidos que afetam dependências declaradas em manifestos e arquivos de bloqueio, diretas e transitivas	Equipes que realizam entregas ativamente, com integração à CI
CSP, Tipos Confiáveis e ZAP	Reforço de segurança contra XSS em tempo de execução e varredura na camada de aplicativos	Equipes especializadas em segurança reforçando a segurança do ambiente de produção
Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para Software de Código Aberto (OSS)	Patches retrocompatíveis para o Angular em fim de vida (versões 4 a 19) e suas dependências compatíveis, disponibilizados via npm	Equipes que estão presas a versões sem suporte e precisam de um software pronto para auditoria, sem a necessidade de uma reescrita forçada

 Verificadores de dependências (Snyk, Dependabot, npm audit)

As ferramentas de análise de composição de software (SCA) monitoram sua árvore de dependências e sinalizam CVEs conhecidos, inclusive em pacotes que você nunca instalou diretamente. Tanto o Snyk quanto o Dependabot do GitHub fazem isso muito bem, e o npm audit vem incluído gratuitamente no npm. O Snyk mantém um amplo banco de dados comercial de vulnerabilidades, e os PRs automatizados do Dependabot facilitam a tarefa de se manter atualizado. Ideal para equipes de desenvolvimento ativas que desejam que a detecção de CVEs seja integrada à CI antes da fusão de códigos.

Fortalecimento em tempo de execução

Os verificadores de dependências detectam problemas conhecidos nos pacotes. Eles não detectam a ausência de uma Política de Segurança de Conteúdo (CSP) nem uma gravação no DOM passível de exploração em seu próprio código. As ferramentas de teste dinâmico de segurança de aplicativos (DAST) — incluindo o Zed Attack Proxy, de código aberto, anteriormente conhecido como OWASP ZAP e agora mantido como ZAP pela Checkmarx — testam o aplicativo em execução em busca de falhas de injeção, cabeçalhos vulneráveis e brechas de CSRF. Ideal para equipes preocupadas com segurança que estejam fortalecendo uma aplicação em produção, em vez de apenas auditar pacotes.

Suporte contínuo ao ciclo de vida do Angular oferecido pela TuxCare

A lacuna mais difícil de ser sanada é a relacionada ao fim do ciclo de vida (EOL). Quando sua versão do Angular deixar de receber correções e a migração não estiver prevista para o curto prazo, os scanners continuarão sinalizando problemas que você não poderá corrigir por meio dos canais oficiais.

O Angular moderno não elimina esse problema, apenas adia o prazo. Toda versão principal acaba perdendo o suporte e, quando isso acontece, ela não é mais elegível para correções de segurança de rotina do desenvolvedor original. A TuxCare faz o backport de correções de segurança para versões do framework sem suporte e para as dependências que ele abrange.

As versões do Angular da 4 à 19 já estão fora de suporte a partir de meados de 2026. Se sua equipe estiver utilizando alguma dessas versões e não puder fazer a atualização em um prazo curto, o Suporte de Ciclo de Vida Ilimitado da TuxCare para o Angular oferece patches de segurança contínuos por meio do npm, o mesmo gerenciador de pacotes que sua equipe já utiliza. A cobertura inclui os pacotes principais do Angular dos quais seu aplicativo depende – @angular/core, @angular/platform-browser, @angular/common, @angular/router, @angular/forms, @angular/cli, @angular/compiler, @angular/compiler-clie @angular/platform-browser-dynamic – além de suas dependências compatíveis, sem custo adicional.

A vantagem prática é bem clara: você continua protegido enquanto planeja a atualização no seu próprio ritmo, em vez de ter que realizar uma migração apressada para resolver um problema em uma auditoria de segurança.

Proteja o Angular com a TuxCare

O Angular oferece um ponto de partida sólido, mas protege apenas partes específicas da aplicação do lado do cliente. O restante fica a cargo da sua equipe: disciplina na sanitização, CSP e Trusted Types, configuração de XSRF em ambas as extremidades, autorização de rotas respaldada por verificações do lado do servidor, controles de scripts de terceiros e correção de dependências.

O aspecto que a maioria das equipes subestima é o que acontece após uma versão do Angular chega ao fim de sua vida útil e as correções oficiais são interrompidas. Essa é a lacuna que o Suporte de Ciclo de Vida Ilimitado da TuxCare da TuxCare foi criado para preencher

A TuxCare oferece suporte a muito mais do que apenas o Angular. Se sua pilha de tecnologias incluir versões sem suporte de outras estruturas ou bibliotecas JavaScript — como React, Vue, AngularJS, jQuery, Next.js, Express e outras —, a TuxCare também oferece suporte a elas. Confira a cobertura atual em Suporte contínuo ao ciclo de vida para bibliotecas e frameworks.

 

Perguntas frequentes