Seguridad

Este tema describe las protecciones integradas de Angular contra vulnerabilidades y ataques comunes de aplicaciones web, como los ataques de cross-site scripting. No cubre la seguridad a nivel de aplicación, como autenticación y autorización.

Para más información sobre los ataques y mitigaciones descritas a continuación, consulta la Guía del Open Web Application Security Project (OWASP).

Mejores prácticas

Estas son algunas mejores prácticas para asegurar que tu aplicación Angular sea segura.

1. Mantente actualizado con las últimas versiones de las bibliotecas de Angular - Las bibliotecas de Angular reciben actualizaciones regulares, y estas actualizaciones pueden corregir defectos de seguridad descubiertos en versiones anteriores. Revisa el registro de cambios de Angular para actualizaciones relacionadas con seguridad.
2. No alteres tu copia de Angular - Las versiones privadas y personalizadas de Angular tienden a quedarse atrás de la versión actual y podrían no incluir correcciones de seguridad importantes y mejoras. En su lugar, comparte tus mejoras de Angular con la comunidad y haz un pull request.
3. Evita las APIs de Angular marcadas en la documentación como "Riesgo de Seguridad" - Para más información, consulta la sección Confiar en valores seguros de esta página.

Prevenir cross-site scripting (XSS)

Cross-site scripting (XSS) permite a los atacantes inyectar código malicioso en páginas web. Dicho código puede, por ejemplo, robar datos de usuario y credenciales de inicio de sesión, o realizar acciones que suplantan al usuario. Este es uno de los ataques más comunes en la web.

Para bloquear ataques XSS, debes evitar que código malicioso entre en el Document Object Model (DOM). Por ejemplo, si los atacantes pueden engañarte para insertar una etiqueta <script> en el DOM, pueden ejecutar código arbitrario en tu sitio web. El ataque no está limitado a etiquetas <script> —muchos elementos y propiedades en el DOM permiten la ejecución de código, por ejemplo, <img alt="" onerror="..."> y <a href="javascript:...">. Si datos controlados por atacantes entran al DOM, espera vulnerabilidades de seguridad.

Modelo de seguridad de Angular contra cross-site scripting

Para bloquear sistemáticamente bugs de XSS, Angular trata todos los valores como no confiables por defecto. Cuando un valor se inserta en el DOM desde un enlace de plantilla o interpolación, Angular sanitiza y escapa los valores no confiables. Si un valor ya fue sanitizado fuera de Angular y se considera seguro, comunícalo a Angular marcando el valor como confiable.

A diferencia de los valores usados para renderizar, las plantillas de Angular se consideran confiables por defecto y deben tratarse como código ejecutable. Nunca crees plantillas concatenando entrada de usuario y sintaxis de plantilla. Hacer esto permitiría a los atacantes inyectar código arbitrario en tu aplicación. Para prevenir estas vulnerabilidades, siempre usa el compilador de plantillas Ahead-Of-Time (AOT) por defecto en despliegues de producción.

Se puede proporcionar una capa extra de protección mediante el uso de Content Security Policy y Trusted Types. Estas características de la plataforma web operan a nivel del DOM, que es el lugar más efectivo para prevenir problemas de XSS. Aquí no pueden ser evadidas usando otras APIs de nivel inferior. Por esta razón, se recomienda encarecidamente aprovechar estas características. Para hacerlo, configura la política de seguridad de contenido para la aplicación y habilita la aplicación de trusted types.

Sanitización y contextos de seguridad

Sanitización es la inspección de un valor no confiable, convirtiéndolo en un valor que es seguro insertar en el DOM. En muchos casos, la sanitización no cambia el valor en absoluto. La sanitización depende del contexto. Por ejemplo, un valor que es inofensivo en CSS es potencialmente peligroso en una URL.

Angular define los siguientes contextos de seguridad:

Angular sanitiza valores no confiables para HTML y URLs. Sanitizar URLs de recursos no es posible porque contienen código arbitrario. En modo de desarrollo, Angular imprime una advertencia en la consola cuando tiene que cambiar un valor durante la sanitización.

Ejemplo de sanitización

La siguiente plantilla enlaza el valor de htmlSnippet. Una vez interpolándolo en el contenido de un elemento, y otra vez enlazándolo a la propiedad innerHTML de un 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>

El contenido interpolado siempre se escapa —el HTML no se interpreta y el navegador muestra los corchetes angulares en el contenido de texto del elemento.

Para que el HTML sea interpretado, enlázalo a una propiedad HTML como innerHTML. Ten en cuenta que enlazar un valor que un atacante podría controlar a innerHTML normalmente causa una vulnerabilidad XSS. Por ejemplo, uno podría ejecutar JavaScript de la siguiente manera:

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>';}

Angular reconoce el valor como inseguro y automáticamente lo sanitiza, lo que elimina el elemento script pero mantiene contenido seguro como el elemento <b>.

Uso directo de las APIs del DOM y llamadas explícitas de sanitización

A menos que apliques Trusted Types, las APIs del DOM integradas del navegador no te protegen automáticamente de vulnerabilidades de seguridad. Por ejemplo, document, el nodo disponible a través de ElementRef, y muchas APIs de terceros contienen métodos inseguros. De igual manera, si interactúas con otras bibliotecas que manipulan el DOM, probablemente no tendrás la misma sanitización automática que con las interpolaciones de Angular. Evita interactuar directamente con el DOM y en su lugar usa plantillas de Angular donde sea posible.

Para casos donde esto es inevitable, usa las funciones de sanitización integradas de Angular. Sanitiza valores no confiables con el método DomSanitizer.sanitize y el SecurityContext apropiado. Esa función también acepta valores que fueron marcados como confiables usando las funciones bypassSecurityTrust, y no los sanitiza, como se describe a continuación.

Confiar en valores seguros

A veces las aplicaciones genuinamente necesitan incluir código ejecutable, mostrar un <iframe> desde alguna URL, o construir URLs potencialmente peligrosas. Para prevenir la sanitización automática en estas situaciones, dile a Angular que inspeccionaste un valor, verificaste cómo fue creado, y te aseguraste de que es seguro. Ten cuidado. Si confías en un valor que podría ser malicioso, estás introduciendo una vulnerabilidad de seguridad en tu aplicación. Si tienes dudas, busca un revisor de seguridad profesional.

Para marcar un valor como confiable, inyecta DomSanitizer y llama uno de los siguientes métodos:

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

Recuerda, si un valor es seguro depende del contexto, así que elige el contexto correcto para el uso previsto del valor. Imagina que la siguiente plantilla necesita enlazar una URL a una llamada 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, Angular sanitiza automáticamente la URL, deshabilita el código peligroso, y en modo de desarrollo, registra esta acción en la consola. Para prevenir esto, marca el valor de la URL como una URL confiable usando la llamada 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);  }}

Si necesitas convertir entrada de usuario en un valor confiable, usa un método del componente. La siguiente plantilla permite a los usuarios ingresar un ID de video de YouTube y cargar el video correspondiente en un <iframe>. El atributo <iframe src> es un contexto de seguridad de URL de recurso, porque una fuente no confiable puede, por ejemplo, infiltrar descargas de archivos que usuarios desprevenidos podrían ejecutar. Para prevenir esto, llama un método en el componente para construir una URL de video confiable, lo que hace que Angular permita el enlace a <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);  }}

Política de seguridad de contenido

Content Security Policy (CSP) es una técnica de defensa en profundidad para prevenir XSS. Para habilitar CSP, configura tu servidor web para devolver un encabezado HTTP Content-Security-Policy apropiado. Lee más sobre la política de seguridad de contenido en la guía de Web Fundamentals en el sitio web de Google Developers.

La política mínima requerida para una aplicación Angular nueva es:

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

Al servir tu aplicación Angular, el servidor debe incluir un nonce generado aleatoriamente en el encabezado HTTP para cada petición. Debes proporcionar este nonce a Angular para que el framework pueda renderizar elementos <style>. Puedes establecer el nonce para Angular de una de estas maneras:

1. Establece la opción autoCsp a true en la configuración del espacio de trabajo.
2. Establece el atributo ngCspNonce en el elemento raíz de la aplicación como <app ngCspNonce="randomNonceGoesHere"></app>. Usa este enfoque si tienes acceso a plantillas del lado del servidor que pueden agregar el nonce tanto al encabezado como al index.html al construir la respuesta.
3. Proporciona el nonce usando el token de inyección CSP_NONCE. Usa este enfoque si tienes acceso al nonce en tiempo de ejecución y quieres poder cachear el index.html.

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

NOTA: Si quieres incluir el CSS crítico en línea de tu aplicación, no puedes usar el token CSP_NONCE, y deberías preferir la opción autoCsp o establecer el atributo ngCspNonce en el elemento raíz de la aplicación.

Si no puedes generar nonces en tu proyecto, puedes permitir estilos en línea agregando 'unsafe-inline' a la sección style-src del encabezado CSP.

Angular en sí solo requiere estas configuraciones para funcionar correctamente. A medida que tu proyecto crece, puede que necesites expandir tu configuración CSP para acomodar características extra específicas de tu aplicación.

Aplicar Trusted Types

Se recomienda que uses Trusted Types como una forma de ayudar a asegurar tus aplicaciones contra ataques de cross-site scripting. Trusted Types es una característica de la plataforma web que puede ayudarte a prevenir ataques de cross-site scripting aplicando prácticas de codificación más seguras. Trusted Types también puede ayudar a simplificar la auditoría del código de la aplicación.

Para aplicar Trusted Types en tu aplicación, debes configurar el servidor web de tu aplicación para emitir encabezados HTTP con una de las siguientes políticas de Angular:

Debes configurar los encabezados HTTP para Trusted Types en las siguientes ubicaciones:

• Infraestructura de servicio de producción
• Angular CLI (ng serve), usando la propiedad headers en el archivo angular.json, para desarrollo local y pruebas de extremo a extremo
• Karma (ng test), usando la propiedad customHeaders en el archivo karma.config.js, para pruebas unitarias

El siguiente es un ejemplo de un encabezado específicamente configurado para Trusted Types y Angular:

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

Un ejemplo de un encabezado específicamente configurado para Trusted Types y aplicaciones Angular que usan cualquiera de los métodos de Angular en DomSanitizer que evaden la seguridad:

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

El siguiente es un ejemplo de un encabezado específicamente configurado para Trusted Types y aplicaciones Angular usando JIT:

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

El siguiente es un ejemplo de un encabezado específicamente configurado para Trusted Types y aplicaciones Angular que usan lazy loading de módulos:

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

Usar el compilador de plantillas AOT

El compilador de plantillas AOT previene toda una clase de vulnerabilidades llamada inyección de plantillas, y mejora enormemente el rendimiento de la aplicación. El compilador de plantillas AOT es el compilador por defecto usado por las aplicaciones de Angular CLI, y deberías usarlo en todos los despliegues de producción.

Una alternativa al compilador AOT es el compilador JIT que compila plantillas a código de plantilla ejecutable dentro del navegador en tiempo de ejecución. Angular confía en el código de plantilla, así que generar dinámicamente plantillas y compilarlas, en particular plantillas que contienen datos de usuario, evade las protecciones integradas de Angular. Este es un anti-patrón de seguridad. Para información sobre cómo construir formularios dinámicamente de forma segura, consulta la guía de Formularios Dinámicos.

Protección XSS del lado del servidor

El HTML construido en el servidor es vulnerable a ataques de inyección. Inyectar código de plantilla en una aplicación Angular es lo mismo que inyectar código ejecutable en la aplicación: Le da al atacante control total sobre la aplicación. Para prevenir esto, usa un lenguaje de plantillas que automáticamente escape valores para prevenir vulnerabilidades XSS en el servidor. No crees plantillas de Angular en el lado del servidor usando un lenguaje de plantillas. Esto conlleva un alto riesgo de introducir vulnerabilidades de inyección de plantillas.

Vulnerabilidades a nivel HTTP

Angular tiene soporte integrado para ayudar a prevenir dos vulnerabilidades HTTP comunes, cross-site request forgery (CSRF o XSRF) y cross-site script inclusion (XSSI). Ambas deben ser mitigadas principalmente en el lado del servidor, pero Angular proporciona helpers para hacer la integración en el lado del cliente más fácil.

Cross-site request forgery

En un cross-site request forgery (CSRF o XSRF), un atacante engaña al usuario para que visite una página web diferente (como evil.com) con código malicioso. Esta página web secretamente envía una petición maliciosa al servidor web de la aplicación (como example-bank.com).

Asume que el usuario está conectado a la aplicación en example-bank.com. El usuario abre un correo electrónico y hace clic en un enlace a evil.com, que se abre en una nueva pestaña.

La página evil.com inmediatamente envía una petición maliciosa a example-bank.com. Quizás es una petición para transferir dinero de la cuenta del usuario a la cuenta del atacante. El navegador automáticamente envía las cookies de example-bank.com, incluyendo la cookie de autenticación, con esta petición.

Si el servidor de example-bank.com carece de protección XSRF, no puede distinguir entre una petición legítima de la aplicación y la petición falsificada de evil.com.

Para prevenir esto, la aplicación debe asegurar que una petición de usuario se origina desde la aplicación real, no desde un sitio diferente. El servidor y el cliente deben cooperar para frustrar este ataque.

En una técnica anti-XSRF común, el servidor de la aplicación envía un token de autenticación creado aleatoriamente en una cookie. El código del cliente lee la cookie y agrega un encabezado de petición personalizado con el token en todas las peticiones siguientes. El servidor compara el valor de la cookie recibida con el valor del encabezado de la petición y rechaza la petición si los valores faltan o no coinciden.

Esta técnica es efectiva porque todos los navegadores implementan la política del mismo origen. Solo el código del sitio web en el que se establecen las cookies puede leer las cookies de ese sitio y establecer encabezados personalizados en las peticiones a ese sitio. Eso significa que solo tu aplicación puede leer este token de cookie y establecer el encabezado personalizado. El código malicioso en evil.com no puede.

Seguridad XSRF/CSRF de HttpClient

HttpClient soporta un mecanismo común usado para prevenir ataques XSRF. Al realizar peticiones HTTP, un interceptor lee un token de una cookie, por defecto XSRF-TOKEN, y lo establece como un encabezado HTTP, X-XSRF-TOKEN. Debido a que solo el código que se ejecuta en tu dominio podría leer la cookie, el backend puede estar seguro de que la petición HTTP vino de tu aplicación cliente y no de un atacante.

Por defecto, un interceptor envía este encabezado en todas las peticiones mutantes (como POST) a URLs relativas, pero no en peticiones GET/HEAD o en peticiones con una URL absoluta.

Para aprovechar esto, tu servidor necesita establecer un token en una cookie de sesión legible por JavaScript llamada XSRF-TOKEN ya sea en la carga de la página o en la primera petición GET. En peticiones subsecuentes el servidor puede verificar que la cookie coincide con el encabezado HTTP X-XSRF-TOKEN, y por lo tanto estar seguro de que solo código ejecutándose en tu dominio podría haber enviado la petición. El token debe ser único para cada usuario y debe ser verificable por el servidor; esto evita que el cliente fabrique sus propios tokens. Establece el token como un digest de la cookie de autenticación de tu sitio con un salt para seguridad adicional.

Para prevenir colisiones en entornos donde múltiples aplicaciones Angular comparten el mismo dominio o subdominio, da a cada aplicación un nombre de cookie único.

Configurar nombres personalizados de cookie/header

Si tu servicio backend usa nombres diferentes para la cookie o el encabezado del token XSRF, usa withXsrfConfiguration para sobrescribir los valores por defecto.

Agrégalo a la llamada provideHttpClient de la siguiente manera:

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

Deshabilitar la protección XSRF

Si el mecanismo de protección XSRF integrado no funciona para tu aplicación, puedes deshabilitarlo usando la característica withNoXsrfProtection:

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

Para información sobre CSRF en el Open Web Application Security Project (OWASP), consulta Cross-Site Request Forgery (CSRF) y Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. El documento de la Universidad de Stanford Robust Defenses for Cross-Site Request Forgery es una fuente rica en detalles.

Consulta también la charla de Dave Smith sobre XSRF en AngularConnect 2016.

Cross-site script inclusion (XSSI)

Cross-site script inclusion, también conocido como vulnerabilidad JSON, puede permitir que el sitio web de un atacante lea datos de una API JSON. El ataque funciona en navegadores más antiguos sobrescribiendo constructores de objetos JavaScript integrados, y luego incluyendo una URL de API usando una etiqueta <script>.

Este ataque solo es exitoso si el JSON devuelto es ejecutable como JavaScript. Los servidores pueden prevenir un ataque prefijando todas las respuestas JSON para hacerlas no ejecutables, por convención, usando la cadena bien conocida ")]}',\n".

La biblioteca HttpClient de Angular reconoce esta convención y automáticamente elimina la cadena ")]}',\n" de todas las respuestas antes de continuar con el parseo.

Para más información, consulta la sección XSSI de esta publicación del blog de seguridad web de Google.

Auditar aplicaciones Angular

Las aplicaciones Angular deben seguir los mismos principios de seguridad que las aplicaciones web regulares, y deben ser auditadas como tales. Las APIs específicas de Angular que deberían ser auditadas en una revisión de seguridad, como los métodos bypassSecurityTrust, están marcadas en la documentación como sensibles a la seguridad.