# Angular
## La Lista de Verificación
Verificar que:
* [ ] Angular se considera un framework del lado del cliente y no se espera que proporcione protección del lado del servidor
* [ ] El sourcemap para los scripts está desactivado en la configuración del proyecto
* [ ] La entrada de usuario no confiable siempre se interpola o se sanea antes de ser utilizada en las plantillas
* [ ] El usuario no tiene control sobre las plantillas del lado del servidor o del lado del cliente
* [ ] La entrada de usuario no confiable se sanea utilizando un contexto de seguridad adecuado antes de ser confiada por la aplicación
* [ ] No se utilizan métodos `BypassSecurity*` con entrada no confiable
* [ ] La entrada de usuario no confiable no se pasa a clases de Angular como `ElementRef`, `Renderer2` y `Document`, ni a otros puntos de entrada de JQuery/DOM
## ¿Qué es Angular?
Angular es un potente framework del lado del cliente que se utiliza ampliamente para construir aplicaciones web dinámicas. Es de código abierto y está mantenido por Google. Una de las características clave de Angular es su uso de TypeScript, un superset tipado de JavaScript que facilita la lectura, el mantenimiento y la depuración del código.
Los mecanismos de seguridad de Angular están diseñados para prevenir vulnerabilidades comunes del lado del cliente, como el cross-site scripting (XSS) y las redirecciones abiertas. Sin embargo, Angular también se puede utilizar en el lado del servidor para generar páginas estáticas. Por lo tanto, la seguridad de Angular debe considerarse desde ambos lados.
## Arquitectura del framework
Para comprender mejor los conceptos básicos de Angular, veamos sus conceptos esenciales.
Un proyecto de Angular común suele tener el siguiente aspecto:
```bash
my-workspace/
├── ... #workspace-wide configuration files
├── src
│ ├── app
│ │ ├── app.module.ts #defines the root module, that tells Angular how to assemble the application
│ │ ├── app.component.ts #defines the logic for the application's root component
│ │ ├── app.component.html #defines the HTML template associated with the root component
│ │ ├── app.component.css #defines the base CSS stylesheet for the root component
│ │ ├── app.component.spec.ts #defines a unit test for the root component
│ │ └── app-routing.module.ts #provides routing capability for the application
│ ├── lib
│ │ └── src #library-specific configuration files
│ ├── index.html #main HTML page, where the component will be rendered in
│ └── ... #application-specific configuration files
├── angular.json #provides workspace-wide and project-specific configuration defaults
└── tsconfig.json #provides the base TypeScript configuration for projects in the workspace
```
Según la documentación, cada aplicación Angular tiene al menos un componente, el componente raíz (`AppComponent`) que conecta una jerarquía de componentes con el DOM. Cada componente define una clase que contiene datos y lógica de la aplicación, y está asociado con una plantilla HTML que define una vista a ser mostrada en un entorno objetivo. El decorador `@Component()` identifica la clase inmediatamente debajo de él como un componente, y proporciona la plantilla y metadatos específicos del componente. El `AppComponent` se define en el archivo `app.component.ts`.
Los módulos de Angular (`NgModules`) declaran un contexto de compilación para un conjunto de componentes que está dedicado a un dominio de aplicación, un flujo de trabajo o un conjunto de capacidades estrechamente relacionadas. Cada aplicación Angular tiene un módulo raíz, convencionalmente llamado `AppModule`, que proporciona el mecanismo de arranque que inicia la aplicación. Una aplicación típicamente contiene muchos módulos funcionales. El `AppModule` se define en el archivo `app.module.ts`.
El módulo `Router` de Angular proporciona un servicio que te permite definir una ruta de navegación entre los diferentes estados de la aplicación y jerarquías de vistas en tu aplicación. El `RouterModule` se define en el archivo `app-routing.module.ts`.
Para datos o lógica que no están asociados con una vista específica y que deseas compartir entre componentes, creas una clase de servicio. La definición de una clase de servicio está precedida inmediatamente por el decorador `@Injectable()`. El decorador proporciona los metadatos que permiten que otros proveedores sean inyectados como dependencias en tu clase. La inyección de dependencias (DI) te permite mantener tus clases de componentes livianas y eficientes. No obtienen datos del servidor, validan la entrada del usuario o registran directamente en la consola; delegan esas tareas a los servicios.
## Configuración de Sourcemap
El framework Angular traduce los archivos TypeScript a código JavaScript siguiendo las opciones del archivo `tsconfig.json` y luego construye un proyecto con la configuración de `angular.json`. Al observar el archivo `angular.json`, hemos observado una opción para habilitar o deshabilitar un sourcemap. Según la documentación de Angular, la configuración predeterminada tiene un archivo sourcemap habilitado para los scripts y no está oculto por defecto:
```json
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": false,
"hidden": false
}
```
Generalmente, los archivos de sourcemap se utilizan con fines de depuración, ya que mapean los archivos generados a sus archivos originales. Por lo tanto, no se recomienda utilizarlos en un entorno de producción. Si los sourcemaps están habilitados, mejoran la legibilidad y ayudan en el análisis de archivos al replicar el estado original del proyecto Angular. Sin embargo, si están deshabilitados, un revisor aún puede analizar un archivo JavaScript compilado manualmente buscando patrones de seguridad.
Además, un archivo JavaScript compilado con un proyecto Angular se puede encontrar en las herramientas de desarrollo del navegador → Fuentes (o Depurador y Fuentes) → \[id].main.js. Dependiendo de las opciones habilitadas, este archivo puede contener la siguiente línea al final `//# sourceMappingURL=[id].main.js.map` o puede que no, si la opción **hidden** está establecida en **true**. Sin embargo, si el sourcemap está deshabilitado para **scripts**, las pruebas se vuelven más complejas y no podemos obtener el archivo. Además, el sourcemap se puede habilitar durante la construcción del proyecto como `ng build --source-map`.
## Data binding
La vinculación se refiere al proceso de comunicación entre un componente y su vista correspondiente. Se utiliza para transferir datos hacia y desde el framework Angular. Los datos se pueden pasar a través de varios medios, como eventos, interpolación, propiedades o mediante el mecanismo de vinculación bidireccional. Además, los datos también se pueden compartir entre componentes relacionados (relación padre-hijo) y entre dos componentes no relacionados utilizando la función de servicio.
Podemos clasificar la vinculación por flujo de datos:
* Fuente de datos al destino de la vista (incluye _interpolación_, _propiedades_, _atributos_, _clases_ y _estilos_); se puede aplicar utilizando `[]` o `{{}}` en la plantilla;
* Destino de la vista a la fuente de datos (incluye _eventos_); se puede aplicar utilizando `()` en la plantilla;
* Bidireccional; se puede aplicar utilizando `[()]` en la plantilla.
La vinculación se puede aplicar a propiedades, eventos y atributos, así como a cualquier miembro público de una directiva fuente:
| TIPO | DESTINO | EJEMPLOS |
| --------- | -------------------------------------------------------- | ------------------------------------------------------------------- |
| Propiedad | Propiedad del elemento, propiedad del componente, propiedad de la directiva | \ |
| Evento | Evento del elemento, evento del componente, evento de la directiva | \