# Angular
## The Checklist
Checklist [from here](https://lsgeurope.com/post/angular-security-checklist).
* [ ] Angular is considered a client-side framework and is not expected to provide server-side protection
* [ ] Sourcemap for scripts is disabled in the project configuration
* [ ] Untrusted user input is always interpolated or sanitized before being used in templates
* [ ] The user has no control over server-side or client-side templates
* [ ] Untrusted user input is sanitized using an appropriate security context before being trusted by the application
* [ ] `BypassSecurity*` methods are not used with untrusted input
* [ ] Untrusted user input is not passed to Angular classes such as `ElementRef` , `Renderer2` and `Document`, or other JQuery/DOM sinks
## What is Angular
Angular is a **powerful** and **open-source** front-end framework maintained by **Google**. It uses **TypeScript** to enhance code readability and debugging. With strong security mechanisms, Angular prevents common client-side vulnerabilities like **XSS** and **open redirects**. It can be used on the **server-side** too, making security considerations important from **both angles**.
## Framework architecture
In order to better understand the Angular basics, let’s go through its essential concepts.
Common Angular project usually looks like:
```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
```
According to the documentation, every Angular application has at least one component, the root component (`AppComponent`) that connects a component hierarchy with the DOM. Each component defines a class that contains application data and logic, and is associated with an HTML template that defines a view to be displayed in a target environment. The `@Component()` decorator identifies the class immediately below it as a component, and provides the template and related component-specific metadata. The `AppComponent` is defined in the `app.component.ts` file.
Angular NgModules declare a compilation context for a set of components that is dedicated to an application domain, a workflow, or a closely related set of capabilities. Every Angular application has a root module, conventionally named `AppModule`, which provides the bootstrap mechanism that launches the application. An application typically contains many functional modules. The `AppModule` is defined in the `app.module.ts` file.
The Angular `Router` NgModule provides a service that lets you define a navigation path among the different application states and view hierarchies in your application. The `RouterModule`is defined in the `app-routing.module.ts` file.
For data or logic that isn't associated with a specific view, and that you want to share across components, you create a service class. A service class definition is immediately preceded by the `@Injectable()` decorator. The decorator provides the metadata that allows other providers to be injected as dependencies into your class. Dependency injection (DI) lets you keep your component classes lean and efficient. They don't fetch data from the server, validate user input, or log directly to the console; they delegate such tasks to services.
## Sourcemap configuration
Angular framework translates TypeScript files into JavaScript code by following `tsconfig.json` options and then builds a project with `angular.json` configuration. Looking at `angular.json` file, we observed an option to enable or disable a sourcemap. According to the Angular documentation, the default configuration has a sourcemap file enabled for scripts and is not hidden by default:
```json
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": false,
"hidden": false
}
```
Generally, sourcemap files are utilized for debugging purposes as they map generated files to their original files. Therefore, it is not recommended to use them in a production environment. If sourcemaps are enabled, it improves the readability and aids in file analysis by replicating the original state of the Angular project. However, if they are disabled, a reviewer can still analyze a compiled JavaScript file manually by searching for anti-security patterns.
Furthemore, a compiled JavaScript file with an Angular project can be found in the browser developer tools → Sources (or Debugger and Sources) → \[id].main.js. Depending on the enabled options, this file may contain the following row in the end `//# sourceMappingURL=[id].main.js.map` or it may not, if the **hidden** option is set to **true**. Nonetheless, if the sourcemap is disabled for **scripts**, testing becomes more complex, and we cannot obtain the file. In addition, sourcemap can be enabled during project build like `ng build --source-map`.
## Data binding
Binding refers to the process of communication between a component and its corresponding view. It is utilized for transferring data to and from the Angular framework. Data can be passed through various means, such as through events, interpolation, properties, or through the two-way binding mechanism. Moreover, data can also be shared between related components (parent-child relation) and between two unrelated components using the Service feature.
We can classify binding by data flow:
* Data source to view target (includes _interpolation_, _properties_, _attributes_, _classes_ and _styles_); can be applied by using `[]` or `{{}}` in template;
* View target to data source (includes _events_); can be applied by using `()` in template;
* Two-Way; can be applied by using `[()]` in template.
Binding can be called on properties, events, and attributes, as well as on any public member of a source directive:
| TYPE | TARGET | EXAMPLES |
| --------- | -------------------------------------------------------- | -------------------------------------------------------------------- |
| Property | Element property, Component property, Directive property | \ |
| Event | Element event, Component event, Directive event | \