# Angular
## A Lista de Verificação
Verifique se:
* [ ] O Angular é considerado um framework do lado do cliente e não é esperado que forneça proteção do lado do servidor
* [ ] O sourcemap para scripts está desabilitado na configuração do projeto
* [ ] A entrada do usuário não confiável é sempre interpolada ou sanitizada antes de ser usada em templates
* [ ] O usuário não tem controle sobre os templates do lado do servidor ou do lado do cliente
* [ ] A entrada do usuário não confiável é sanitizada usando um contexto de segurança apropriado antes de ser confiada pela aplicação
* [ ] Os métodos `BypassSecurity*` não são usados com entrada não confiável
* [ ] A entrada do usuário não confiável não é passada para classes Angular como `ElementRef`, `Renderer2` e `Document`, ou outros pontos de injeção de JQuery/DOM
## O que é o Angular
O Angular é um poderoso framework front-end amplamente utilizado para construir aplicações web dinâmicas. É de código aberto e mantido pelo Google. Uma das principais características do Angular é o uso do TypeScript, um superset tipado do JavaScript que torna o código mais fácil de ler, manter e depurar.
Os mecanismos de segurança do Angular são projetados para prevenir vulnerabilidades comuns do lado do cliente, incluindo cross-site scripting (XSS) e redirecionamentos abertos. No entanto, o Angular também pode ser usado no lado do servidor para gerar páginas estáticas. Portanto, a segurança do Angular deve ser considerada de ambos os lados.
## Arquitetura do framework
Para entender melhor os conceitos básicos do Angular, vamos analisar seus conceitos essenciais.
Um projeto Angular comum geralmente se parece com:
```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
```
De acordo com a documentação, cada aplicação Angular tem pelo menos um componente, o componente raiz (`AppComponent`), que conecta uma hierarquia de componentes com o DOM. Cada componente define uma classe que contém dados e lógica da aplicação, e está associado a um template HTML que define uma visualização a ser exibida em um ambiente alvo. O decorador `@Component()` identifica a classe imediatamente abaixo dele como um componente e fornece o template e metadados específicos do componente. O `AppComponent` é definido no arquivo `app.component.ts`.
Os módulos NgModules do Angular declaram um contexto de compilação para um conjunto de componentes dedicados a um domínio de aplicação, um fluxo de trabalho ou um conjunto de capacidades intimamente relacionadas. Toda aplicação Angular tem um módulo raiz, convencionalmente chamado de `AppModule`, que fornece o mecanismo de inicialização que inicia a aplicação. Uma aplicação geralmente contém muitos módulos funcionais. O `AppModule` é definido no arquivo `app.module.ts`.
O NgModule `Router` do Angular fornece um serviço que permite definir um caminho de navegação entre os diferentes estados da aplicação e hierarquias de visualização em sua aplicação. O `RouterModule` é definido no arquivo `app-routing.module.ts`.
Para dados ou lógica que não estão associados a uma visualização específica e que você deseja compartilhar entre componentes, você cria uma classe de serviço. A definição da classe de serviço é imediatamente precedida pelo decorador `@Injectable()`. O decorador fornece os metadados que permitem que outros provedores sejam injetados como dependências em sua classe. A injeção de dependência (DI) permite que você mantenha suas classes de componente enxutas e eficientes. Elas não buscam dados do servidor, validam a entrada do usuário ou registram diretamente no console; elas delegam essas tarefas para serviços.
## Configuração do sourcemap
O framework Angular traduz arquivos TypeScript em código JavaScript seguindo as opções do arquivo `tsconfig.json` e, em seguida, constrói um projeto com a configuração do arquivo `angular.json`. Ao analisar o arquivo `angular.json`, observamos uma opção para habilitar ou desabilitar um sourcemap. De acordo com a documentação do Angular, a configuração padrão possui um arquivo sourcemap habilitado para scripts e não está oculto por padrão:
```json
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": false,
"hidden": false
}
```
Geralmente, os arquivos de sourcemap são utilizados para fins de depuração, pois eles mapeiam arquivos gerados para seus arquivos originais. Portanto, não é recomendado utilizá-los em um ambiente de produção. Se os sourcemaps estiverem habilitados, eles melhoram a legibilidade e auxiliam na análise de arquivos, replicando o estado original do projeto Angular. No entanto, se eles estiverem desabilitados, um revisor ainda pode analisar um arquivo JavaScript compilado manualmente, procurando por padrões anti-segurança.
Além disso, um arquivo JavaScript compilado com um projeto Angular pode ser encontrado nas ferramentas de desenvolvedor do navegador → Sources (ou Debugger e Sources) → \[id].main.js. Dependendo das opções habilitadas, esse arquivo pode conter a seguinte linha no final `//# sourceMappingURL=[id].main.js.map` ou pode não conter, se a opção **hidden** estiver definida como **true**. No entanto, se o sourcemap estiver desabilitado para **scripts**, os testes se tornam mais complexos e não podemos obter o arquivo. Além disso, o sourcemap pode ser habilitado durante a construção do projeto, como `ng build --source-map`.
## Data binding
Binding refere-se ao processo de comunicação entre um componente e sua visualização correspondente. É utilizado para transferir dados para e do framework Angular. Os dados podem ser passados por meio de vários meios, como eventos, interpolação, propriedades ou por meio do mecanismo de binding bidirecional. Além disso, os dados também podem ser compartilhados entre componentes relacionados (relação pai-filho) e entre dois componentes não relacionados usando o recurso de Serviço.
Podemos classificar o binding pelo fluxo de dados:
* Fonte de dados para alvo de visualização (inclui _interpolação_, _propriedades_, _atributos_, _classes_ e _estilos_); pode ser aplicado usando `[]` ou `{{}}` no template;
* Alvo de visualização para fonte de dados (inclui _eventos_); pode ser aplicado usando `()` no template;
* Bidirecional; pode ser aplicado usando `[()]` no template.
O binding pode ser realizado em propriedades, eventos e atributos, bem como em qualquer membro público de uma diretiva de origem:
| TIPO | ALVO | EXEMPLOS |
| --------- | -------------------------------------------------------- | -------------------------------------------------------------------- |
| Propriedade | Propriedade do elemento, propriedade do componente, propriedade da diretiva | \ |
| Evento | Evento do elemento, evento do componente, evento da diretiva | \