# Angular
## Die Checkliste
Checkliste [von hier](https://lsgeurope.com/post/angular-security-checklist).
* [ ] Angular wird als Client-seitiges Framework betrachtet und wird nicht erwartet, serverseitigen Schutz zu bieten
* [ ] Sourcemap für Skripte ist in der Projektkonfiguration deaktiviert
* [ ] Nicht vertrauenswürdige Benutzereingaben werden immer interpoliert oder bereinigt, bevor sie in Vorlagen verwendet werden
* [ ] Der Benutzer hat keine Kontrolle über serverseitige oder clientseitige Vorlagen
* [ ] Nicht vertrauenswürdige Benutzereingaben werden vor der Verwendung durch die Anwendung mit einem geeigneten Sicherheitskontext bereinigt
* [ ] `BypassSecurity*`-Methoden werden nicht mit nicht vertrauenswürdigen Eingaben verwendet
* [ ] Nicht vertrauenswürdige Benutzereingaben werden nicht an Angular-Klassen wie `ElementRef`, `Renderer2` und `Document` oder andere JQuery/DOM-Senken übergeben
## Was ist Angular
Angular ist ein **leistungsstarkes** und **Open-Source**-Front-End-Framework, das von **Google** gepflegt wird. Es verwendet **TypeScript**, um die Lesbarkeit und das Debugging des Codes zu verbessern. Mit starken Sicherheitsmechanismen verhindert Angular gängige Client-seitige Sicherheitslücken wie **XSS** und **offene Weiterleitungen**. Es kann auch auf der **Serverseite** verwendet werden, wodurch Sicherheitsüberlegungen von **beiden Seiten** wichtig sind.
## Framework-Architektur
Um die Grundlagen von Angular besser zu verstehen, gehen wir durch seine wesentlichen Konzepte.
Ein typisches Angular-Projekt sieht normalerweise so aus:
```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
```
Gemäß der Dokumentation hat jede Angular-Anwendung mindestens eine Komponente, die Wurzelkomponente (`AppComponent`), die eine Komponentenhierarchie mit dem DOM verbindet. Jede Komponente definiert eine Klasse, die Anwendungsdaten und -logik enthält und mit einer HTML-Vorlage verknüpft ist, die eine Ansicht definiert, die in einer Zielumgebung angezeigt werden soll. Der `@Component()`-Dekorator kennzeichnet die unmittelbar darunter liegende Klasse als Komponente und stellt die Vorlage und die zugehörigen komponentenspezifischen Metadaten bereit. Die `AppComponent` ist in der Datei `app.component.ts` definiert.
Angular NgModules deklarieren einen Kompilierungskontext für eine Gruppe von Komponenten, die einem Anwendungsbereich, einem Arbeitsablauf oder einem eng verwandten Satz von Funktionen gewidmet sind. Jede Angular-Anwendung hat ein Root-Modul, das konventionell `AppModule` genannt wird und den Bootstrap-Mechanismus bereitstellt, der die Anwendung startet. Eine Anwendung enthält in der Regel viele funktionale Module. Das `AppModule` ist in der Datei `app.module.ts` definiert.
Das Angular `Router` NgModule stellt einen Dienst bereit, mit dem Sie einen Navigationspfad zwischen den verschiedenen Anwendungszuständen und Ansichtshierarchien in Ihrer Anwendung definieren können. Das `RouterModule` ist in der Datei `app-routing.module.ts` definiert.
Für Daten oder Logik, die nicht mit einer bestimmten Ansicht verknüpft sind und die Sie über Komponenten hinweg teilen möchten, erstellen Sie eine Serviceklasse. Die Definition einer Serviceklasse wird unmittelbar vom `@Injectable()`-Dekorator vorangestellt. Der Dekorator stellt Metadaten bereit, die es anderen Providern ermöglichen, als Abhängigkeiten in Ihre Klasse injiziert zu werden. Die Dependency Injection (DI) ermöglicht es Ihnen, Ihre Komponentenklassen schlank und effizient zu halten. Sie rufen keine Daten vom Server ab, validieren keine Benutzereingaben und protokollieren nicht direkt in die Konsole; diese Aufgaben werden an Services delegiert.
## Sourcemap-Konfiguration
Das Angular-Framework übersetzt TypeScript-Dateien in JavaScript-Code, indem es die Optionen der `tsconfig.json` befolgt und dann ein Projekt mit der Konfiguration der `angular.json` erstellt. Beim Betrachten der Datei `angular.json` haben wir eine Option zur Aktivierung oder Deaktivierung einer Sourcemap festgestellt. Gemäß der Angular-Dokumentation ist die Standardkonfiguration für Skripte eine aktivierte Sourcemap-Datei, die standardmäßig nicht ausgeblendet ist:
```json
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": false,
"hidden": false
}
```
Generell werden Sourcemap-Dateien zu Debugging-Zwecken verwendet, da sie generierte Dateien ihren Originaldateien zuordnen. Daher wird nicht empfohlen, sie in einer Produktionsumgebung zu verwenden. Wenn Sourcemaps aktiviert sind, verbessert dies die Lesbarkeit und erleichtert die Dateianalyse, indem der ursprüngliche Zustand des Angular-Projekts repliziert wird. Wenn sie jedoch deaktiviert sind, kann ein Überprüfer eine kompilierte JavaScript-Datei immer noch manuell analysieren, indem er nach Anti-Sicherheitsmustern sucht.
Darüber hinaus kann eine kompilierte JavaScript-Datei mit einem Angular-Projekt in den Browser-Entwicklertools → Quellen (oder Debugger und Quellen) → \[id].main.js gefunden werden. Abhängig von den aktivierten Optionen kann diese Datei die folgende Zeile am Ende enthalten `//# sourceMappingURL=[id].main.js.map` oder auch nicht, wenn die **hidden**-Option auf **true** gesetzt ist. Wenn die Sourcemap jedoch für **Skripte** deaktiviert ist, wird das Testen komplexer und wir können die Datei nicht erhalten. Darüber hinaus kann die Sourcemap während des Projektbuilds aktiviert werden, z.B. mit `ng build --source-map`.
## Datenbindung
Binding bezieht sich auf den Prozess der Kommunikation zwischen einer Komponente und ihrer entsprechenden Ansicht. Es wird verwendet, um Daten zwischen dem Angular-Framework zu übertragen. Daten können auf verschiedene Weise übertragen werden, z.B. durch Ereignisse, Interpolation, Eigenschaften oder durch den Mechanismus der bidirektionalen Bindung. Darüber hinaus können Daten zwischen verwandten Komponenten (Eltern-Kind-Beziehung) und zwischen zwei nicht verwandten Komponenten mithilfe der Service-Funktion geteilt werden.
Wir können die Bindung nach Datenfluss klassifizieren:
* Datenquelle zum Ansichtsziel (umfasst _Interpolation_, _Eigenschaften_, _Attribute_, _Klassen_ und _Styles_); kann mit `[]` oder `{{}}` in der Vorlage angewendet werden;
* Ansichtsziel zur Datenquelle (umfasst _Ereignisse_); kann mit `()` in der Vorlage angewendet werden;
* Bidirektional; kann mit `[()]` in der Vorlage angewendet werden.
Binding kann auf Eigenschaften, Ereignisse und Attribute angewendet werden, sowie auf jedes öffentliche Element einer Quellrichtlinie:
| TYP | ZIEL | BEISPIELE |
| --------- | -------------------------------------------------------- | -------------------------------------------------------------------- |
| Eigenschaft | Elementeigenschaft, Komponenteneigenschaft, Direktiveigenschaft | \ |
| Ereignis | Elementereignis, Komponentenereignis, Direktiveereignis | \