# Angular
## The Checklist
Checklist [from here](https://lsgeurope.com/post/angular-security-checklist).
* [ ] Angular को एक क्लाइंट-साइड फ्रेमवर्क माना जाता है और इसे सर्वर-साइड सुरक्षा प्रदान करने की अपेक्षा नहीं की जाती है
* [ ] प्रोजेक्ट कॉन्फ़िगरेशन में स्क्रिप्ट के लिए सोर्समैप अक्षम है
* [ ] अविश्वसनीय उपयोगकर्ता इनपुट को हमेशा टेम्पलेट्स में उपयोग करने से पहले इंटरपोलेट या सैनीटाइज किया जाता है
* [ ] उपयोगकर्ता के पास सर्वर-साइड या क्लाइंट-साइड टेम्पलेट्स पर कोई नियंत्रण नहीं है
* [ ] अविश्वसनीय उपयोगकर्ता इनपुट को एप्लिकेशन द्वारा विश्वसनीय होने से पहले एक उपयुक्त सुरक्षा संदर्भ का उपयोग करके सैनीटाइज किया जाता है
* [ ] `BypassSecurity*` विधियों का अविश्वसनीय इनपुट के साथ उपयोग नहीं किया जाता है
* [ ] अविश्वसनीय उपयोगकर्ता इनपुट को Angular क्लासेस जैसे `ElementRef`, `Renderer2` और `Document`, या अन्य JQuery/DOM सिंक्स में नहीं भेजा जाता है
## What is Angular
Angular एक **शक्तिशाली** और **ओपन-सोर्स** फ्रंट-एंड फ्रेमवर्क है जिसे **Google** द्वारा बनाए रखा जाता है। यह कोड की पठनीयता और डिबगिंग को बढ़ाने के लिए **TypeScript** का उपयोग करता है। मजबूत सुरक्षा तंत्र के साथ, Angular सामान्य क्लाइंट-साइड कमजोरियों जैसे **XSS** और **open redirects** को रोकता है। इसे **सर्वर-साइड** पर भी उपयोग किया जा सकता है, जिससे **दोनों कोणों** से सुरक्षा पर विचार करना महत्वपूर्ण हो जाता है।
## Framework architecture
Angular के मूलभूत सिद्धांतों को बेहतर ढंग से समझने के लिए, आइए इसके आवश्यक अवधारणाओं के माध्यम से चलते हैं।
सामान्य Angular प्रोजेक्ट आमतौर पर इस तरह दिखता है:
```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
```
अन्य दस्तावेज़ के अनुसार, हर Angular एप्लिकेशन में कम से कम एक घटक होता है, रूट घटक (`AppComponent`) जो घटक पदानुक्रम को DOM से जोड़ता है। प्रत्येक घटक एक वर्ग को परिभाषित करता है जिसमें एप्लिकेशन डेटा और लॉजिक होता है, और यह एक HTML टेम्पलेट से संबंधित होता है जो एक लक्षित वातावरण में प्रदर्शित होने वाले दृश्य को परिभाषित करता है। `@Component()` डेकोरेटर उस वर्ग को घटक के रूप में पहचानता है जो इसके ठीक नीचे है, और टेम्पलेट और संबंधित घटक-विशिष्ट मेटाडेटा प्रदान करता है। `AppComponent` को `app.component.ts` फ़ाइल में परिभाषित किया गया है।
Angular NgModules एक एप्लिकेशन डोमेन, एक कार्यप्रवाह, या निकटता से संबंधित क्षमताओं के सेट के लिए एक संकलन संदर्भ घोषित करते हैं। हर Angular एप्लिकेशन में एक रूट मॉड्यूल होता है, जिसे पारंपरिक रूप से `AppModule` कहा जाता है, जो एप्लिकेशन को लॉन्च करने के लिए बूटस्ट्रैप तंत्र प्रदान करता है। एक एप्लिकेशन में आमतौर पर कई कार्यात्मक मॉड्यूल होते हैं। `AppModule` को `app.module.ts` फ़ाइल में परिभाषित किया गया है।
Angular `Router` NgModule एक सेवा प्रदान करता है जो आपको अपने एप्लिकेशन में विभिन्न एप्लिकेशन राज्यों और दृश्य पदानुक्रमों के बीच एक नेविगेशन पथ परिभाषित करने की अनुमति देता है। `RouterModule` को `app-routing.module.ts` फ़ाइल में परिभाषित किया गया है।
डेटा या लॉजिक के लिए जो किसी विशिष्ट दृश्य से संबंधित नहीं है, और जिसे आप घटकों के बीच साझा करना चाहते हैं, आप एक सेवा वर्ग बनाते हैं। एक सेवा वर्ग परिभाषा के तुरंत पहले `@Injectable()` डेकोरेटर होता है। डेकोरेटर मेटाडेटा प्रदान करता है जो अन्य प्रदाताओं को आपकी कक्षा में निर्भरता के रूप में इंजेक्ट करने की अनुमति देता है। निर्भरता इंजेक्शन (DI) आपको अपने घटक वर्गों को पतला और कुशल बनाए रखने की अनुमति देता है। वे सर्वर से डेटा नहीं लाते, उपयोगकर्ता इनपुट को मान्य नहीं करते, या सीधे कंसोल में लॉग नहीं करते; वे ऐसी कार्यों को सेवाओं को सौंपते हैं।
## Sourcemap configuration
Angular फ्रेमवर्क TypeScript फ़ाइलों को JavaScript कोड में अनुवाद करता है `tsconfig.json` विकल्पों का पालन करते हुए और फिर `angular.json` कॉन्फ़िगरेशन के साथ एक प्रोजेक्ट बनाता है। `angular.json` फ़ाइल को देखते हुए, हमने एक विकल्प देखा जो एक sourcemap को सक्षम या अक्षम करने के लिए है। Angular दस्तावेज़ के अनुसार, डिफ़ॉल्ट कॉन्फ़िगरेशन में स्क्रिप्ट के लिए एक sourcemap फ़ाइल सक्षम होती है और यह डिफ़ॉल्ट रूप से छिपी नहीं होती है:
```json
"sourceMap": {
"scripts": true,
"styles": true,
"vendor": false,
"hidden": false
}
```
आम तौर पर, sourcemap फ़ाइलों का उपयोग डिबगिंग उद्देश्यों के लिए किया जाता है क्योंकि ये उत्पन्न फ़ाइलों को उनके मूल फ़ाइलों से मैप करती हैं। इसलिए, इन्हें उत्पादन वातावरण में उपयोग करने की सिफारिश नहीं की जाती है। यदि sourcemaps सक्षम हैं, तो यह पठनीयता में सुधार करता है और Angular प्रोजेक्ट की मूल स्थिति को दोहराकर फ़ाइल विश्लेषण में मदद करता है। हालाँकि, यदि इन्हें अक्षम किया गया है, तो एक समीक्षक अभी भी एंटी-सुरक्षा पैटर्न की खोज करके एक संकलित JavaScript फ़ाइल का मैन्युअल रूप से विश्लेषण कर सकता है।
इसके अलावा, एक संकलित JavaScript फ़ाइल Angular प्रोजेक्ट के साथ ब्राउज़र डेवलपर टूल्स → Sources (या Debugger और Sources) → \[id].main.js में पाई जा सकती है। सक्षम विकल्पों के आधार पर, इस फ़ाइल के अंत में निम्नलिखित पंक्ति हो सकती है `//# sourceMappingURL=[id].main.js.map` या यह नहीं हो सकती, यदि **hidden** विकल्प **true** पर सेट है। फिर भी, यदि **scripts** के लिए sourcemap अक्षम है, तो परीक्षण अधिक जटिल हो जाता है, और हम फ़ाइल प्राप्त नहीं कर सकते। इसके अलावा, प्रोजेक्ट निर्माण के दौरान sourcemap को सक्षम किया जा सकता है जैसे `ng build --source-map`।
## डेटा बाइंडिंग
बाइंडिंग उस प्रक्रिया को संदर्भित करती है जिसमें एक घटक और इसके संबंधित दृश्य के बीच संचार होता है। इसका उपयोग Angular ढांचे के लिए डेटा को स्थानांतरित करने के लिए किया जाता है। डेटा को विभिन्न तरीकों से पास किया जा सकता है, जैसे कि घटनाओं, इंटरपोलेशन, गुणों, या दो-तरफा बाइंडिंग तंत्र के माध्यम से। इसके अलावा, डेटा को संबंधित घटकों (माता-पिता-शिशु संबंध) और दो अप्रासंगिक घटकों के बीच सेवा सुविधा का उपयोग करके भी साझा किया जा सकता है।
हम डेटा प्रवाह द्वारा बाइंडिंग को वर्गीकृत कर सकते हैं:
* डेटा स्रोत से दृश्य लक्ष्य (जिसमें _interpolation_, _properties_, _attributes_, _classes_ और _styles_ शामिल हैं); इसे टेम्पलेट में `[]` या `{{}}` का उपयोग करके लागू किया जा सकता है;
* दृश्य लक्ष्य से डेटा स्रोत (जिसमें _events_ शामिल हैं); इसे टेम्पलेट में `()` का उपयोग करके लागू किया जा सकता है;
* दो-तरफा; इसे टेम्पलेट में `[()]` का उपयोग करके लागू किया जा सकता है।
बाइंडिंग को गुणों, घटनाओं, और विशेषताओं पर, साथ ही स्रोत निर्देशिका के किसी भी सार्वजनिक सदस्य पर बुलाया जा सकता है:
| TYPE | TARGET | EXAMPLES |
| --------- | -------------------------------------------------------- | -------------------------------------------------------------------- |
| Property | Element property, Component property, Directive property | \ |
| Event | Element event, Component event, Directive event | \