Security Audit Report ngx-admin Generated by Inkwell Forge — automated codebase documentation analysis. Based on analysis of 100 screens. Subject matter expert review is recommended before distribution. R E P O RT D AT E · M AY 3 , 2 0 2 6

-- 1 of 38 --

Security Audit Report Executive Summary Audit Methodology Framework and Standards Scope Limitations Severity Definitions (CVSS-Aligned) Risk Summary Dashboard OWASP Top 10 Coverage Screen-by-Screen Findings Global / Cross-Cutting Findings Finding Inventory Needs Verification AVSV Compliance Summary Remediation Roadmap Phase 1: Immediate (0–7 days) — No Critical findings identified Phase 2: Short-Term (1–4 weeks) — All High findings Phase 3: Medium-Term (1–3 months) — All Medium findings Phase 4: Backlog — Low and Info findings Positive Security Patterns Glossary Security Terms OWASP Top 10 Categories CWE Weakness Types AVSV Chapter Names Acronyms Page 2 of 38

-- 2 of 38 --

Security Audit Report Application: ngx-admin Document Title: Security Audit Report Date: May 2026 Assessment Scope: 100 screens across the ngx-admin Angular dashboard application Executive Summary Generated by Inkwell Forge — automated codebase documentation analysis. Subject matter expert review is recommended before distribution. This security audit assessed 100 screens of the ngx-admin Angular dashboard application, a Nebular-based open-source admin template by Akveo. The overall security posture is rated Moderate. The application demonstrates several sound security practices — particularly consistent RxJS subscription lifecycle management, Angular's built-in template auto-escaping, and a clean separation of authentication concerns into route guards — but exhibits a cluster of recurring weaknesses that, taken together, represent meaningful risk in a production deployment. The application's most significant strengths are its consistent use of Angular's template binding system (which auto-escapes interpolated values, providing baseline XSS protection), its use of abstract service classes that cleanly separate data-access concerns from UI components, and its adoption of Nebular's NbDialogService and overlay infrastructure, which avoids direct DOM manipulation. Three findings warrant immediate attention from a business-impact perspective. First, the TinyMCE rich-text editor component emits raw, unsanitized HTML to parent components; if any parent renders this output via [innerHTML] without server-side sanitization, stored XSS is possible — a finding with direct data-integrity and user-safety implications. Second, the application loads TinyMCE and CKEditor assets from external CDNs without Subresource Integrity (SRI) hashes, meaning a compromised CDN could silently inject malicious scripts into every user session. Third, the Google Maps API key is a client-exposed credential with no documented domain restriction, creating a quota-abuse and financial-exposure risk. Security Audit Report Security Audit Report Page 3 of 38

-- 3 of 38 --

Beyond these three, the audit identified a broad pattern of absent error handling on RxJS subscriptions, missing security logging and monitoring instrumentation across all 100 screens, and a high-frequency polling pattern (200 ms interval) in the earning card component that would be untenable against a real backend. See the Finding Inventory for the complete catalog of findings by severity. This assessment is based entirely on technical documentation review. It is not a substitute for dynamic application security testing (DAST), static application security testing (SAST), or penetration testing against a running instance. Audit Methodology Framework and Standards Standard Version Application OWASP Application Security Verification Standard (ASVS) 4.0.3 Verification requirements across 14 chapters OWASP Top 10 2021 Risk categorization for web applications CWE/SANS Top 25 Current Weakness enumeration and severity classification NIST SP 800-53 Rev 5 Security control families and assessment criteria Scope All 100 screens provided in the documentation were assessed. The assessment covers authentication patterns, authorization logic, input validation, API security, data handling, error behaviors, third-party integrations, and client-side security patterns as documented. Security Audit Report Security Audit Report Page 4 of 38

-- 4 of 38 --

Limitations This assessment is based on technical documentation review, not dynamic application security testing (DAST) or static application security testing (SAST). Findings marked "(documented behavior — verify with penetration testing)" require live testing to confirm exploitability. Findings marked "(not documented — requires security testing to confirm)" require additional information or testing. Severity Definitions (CVSS-Aligned) Severity CVSS Range Definition SLA Critical 9.0–10.0 Exploitable vulnerability allowing unauthorized access, data breach, or system compromise Fix immediately (24h) High 7.0–8.9 Significant vulnerability with high probability of exploitation and serious impact Fix within 1 week Medium 4.0–6.9 Moderate vulnerability requiring specific conditions to exploit Fix within 30 days Low 0.1–3.9 Minor security weakness with limited exploitability or impact Fix within 90 days Info 0.0 Security best practice recommendation or hardening suggestion Consider for future work Security Audit Report Security Audit Report Page 5 of 38

-- 5 of 38 --

Risk Summary Dashboard Metric Value Screens Assessed 100 OWASP Top 10 Categories Triggered A01 · A03 · A05 · A06 · A08 · A09 · A10 — 7 of 10 AVSV Chapters Covered V1, V2, V3, V4, V5, V7, V8, V9, V10, V11, V13, V14 Risk Posture Moderate Findings Distribution See Finding Inventory below Security Audit Report Security Audit Report Page 6 of 38

-- 6 of 38 --

OWASP Top 10 Coverage

Category Status Findings Notes

A01 Broken Access Control Concern 2 Route-guard-only enforcement; no component-level authorization checks documented A02 Cryptographic Failures Pass 0 No cryptographic operations documented at the screen layer; HTTPS assumed at infrastructure level A03 Injection Concern 2 TinyMCE raw HTML output; unsanitized countryId passed to service layer A04 Insecure Design Pass 0 No insecure design patterns identified beyond issues captured in other categories A05 Security Misconfiguration High 2 CDN assets loaded without SRI; CKEditor protocol-relative URL A06 Vulnerable & Outdated Components High 1 Multiple severely outdated dependencies identified in PROJECT MANIFEST A07 Identification & Authentication Failures Pass 0 Authentication delegated to Nebular Auth; no custom auth logic in scope A08 Software & Data Integrity Failures High 1 CDN script loading without integrity verification A09 Security Logging & Monitoring Failures Fail 1 Zero security logging or monitoring instrumentation across all 100 screens A10 Server-Side Request Forgery (SSRF) Pass 0 No server-side request construction documented in screen layer Status definitions: Pass — no findings; Concern — Low/Medium findings; Fail — High/Critical findings. Security Audit Report Security Audit Report Page 7 of 38

-- 7 of 38 --

Screen-by-Screen Findings Given the 100-screen scope and the consolidation requirement, findings are grouped by root cause and cross- referenced to all affected screens. Each finding section below identifies the affected screens explicitly. Global / Cross-Cutting Findings These findings apply to the entire application and are not specific to a single screen. SEC-001: No Security Logging or Monitoring Instrumentation Across All Screens Field Value Severity High OWASP Category A09: Security Logging & Monitoring Failures CWE CWE-778: Insufficient Logging AVSV Requirement V7.1.1 — Verify that the application does not log credentials or payment details Component All 100 documented screens Affected Data Security events, authentication failures, authorization violations, input validation failures Description: Every single one of the 100 documented screens explicitly states that no console.log , console.warn , console.error , error tracking service calls (Sentry, DataDog, LogRocket, Bugsnag), or analytics event calls (PostHog, Mixpanel, Google Analytics) are present. The PROJECT MANIFEST confirms no security-monitoring-related packages (e.g., @sentry/angular , @datadog/browser-logs , @bugsnag/js ) appear in the dependency list. This means the application has zero observability into security-relevant events: failed authentication attempts, authorization violations, unexpected errors, and anomalous user behavior are all invisible to operators. In a production deployment, this makes incident detection and forensic investigation impossible. Security Audit Report Security Audit Report Page 8 of 38

-- 8 of 38 --

Evidence: Every screen's Section 10 (Error Handling & Edge Cases) contains the statement: "No console.log , console.warn , console.error , error tracking service calls (Sentry, DataDog, etc.), or analytics event calls are present anywhere in this component's source code." The PROJECT MANIFEST contains no packages matching known security monitoring SDKs. Attack Scenario: An attacker who successfully exploits any vulnerability in this application — whether XSS, unauthorized access, or data exfiltration — would leave no trace in any monitoring system. The attack could persist indefinitely without detection. Additionally, brute-force attempts against any authenticated endpoint would generate no alerts. Remediation: Install a security-aware error tracking SDK. Based on the PROJECT MANIFEST, no monitoring package is currently present; add @sentry/angular (or equivalent) to package.json and configure it with a DSN pointing to your Sentry project. Instrument security-relevant events: authentication success/failure, authorization denials, unexpected API errors (4xx/5xx), and form validation failures. Configure alerting rules in your monitoring platform for anomalous event rates (e.g., >10 auth failures per minute from a single IP). Verify instrumentation is active by triggering a test error and confirming it appears in the monitoring dashboard. Source Evidence: All 100 screens; PROJECT MANIFEST ( package.json ) SEC-002: Severely Outdated Dependencies with Known Vulnerabilities 1. 2. 3. 4. Security Audit Report Security Audit Report Page 9 of 38

-- 9 of 38 --

Field Value Severity High OWASP Category A06: Vulnerable & Outdated Components CWE CWE-1104: Use of Unmaintained Third-Party Components AVSV Requirement V14.2.1 — Verify that all components are up to date Component package.json — multiple production dependencies Affected Data All application data; potential for RCE, XSS, or data exposure depending on CVE Description: The PROJECT MANIFEST reveals multiple production dependencies that are severely outdated and have reached end-of-life or have known CVEs. Key examples: ckeditor: 4.7.3 — CKEditor 4 reached end-of-life in June 2023; version 4.7.3 is from approximately 2017 and has numerous known XSS vulnerabilities. tinymce: 4.5.7 — TinyMCE 4.x is end-of-life; version 4.5.7 is from approximately 2017. chart.js: 2.7.1 — Chart.js 2.x is end-of-life; current is 4.x. bootstrap: 4.3.1 — Bootstrap 4.3.1 has known XSS vulnerabilities (CVE-2019-8331 and others). leaflet: 1.2.0 — Leaflet 1.2.0 is from 2017; current is 1.9.x. core-js: 2.5.1 — core-js 2.x is end-of-life. rxjs: 6.6.2 — While not end-of-life, this is significantly behind current (7.x). @angular/*: ^15.2.10 — Angular 15 reached end-of-life in May 2024. Evidence: package.json dependencies section in PROJECT MANIFEST. Attack Scenario: An attacker targeting a user of this application could exploit a known XSS vulnerability in Bootstrap 4.3.1 (CVE-2019-8331, affecting the data-template attribute in tooltips/popovers) to execute arbitrary JavaScript in the victim's browser, potentially stealing session tokens or performing actions on behalf of the user. Remediation: Run npm audit to generate a full CVE report against the current dependency tree. • • • • • • • • 1. Security Audit Report Security Audit Report Page 10 of 38

-- 10 of 38 --

Prioritize upgrading ckeditor (migrate to CKEditor 5), tinymce (migrate to TinyMCE 6/7 with a valid license or self-hosted deployment), and bootstrap (upgrade to 5.x). Upgrade Angular from 15.x to the current LTS version (18.x or later). Establish a dependency update policy: run npm audit in CI on every pull request and block merges on high/critical CVEs. Verify the application functions correctly after each major dependency upgrade with regression testing. Source Evidence: PROJECT MANIFEST ( package.json ) SEC-003: CDN Asset Loading Without Subresource Integrity (SRI) Field Value Severity High OWASP Category A08: Software & Data Integrity Failures CWE CWE-353: Missing Support for Integrity Check AVSV Requirement V14.2.3 — Verify that third-party components come from pre-defined, trusted repositories Component CKEditor loader ( ckeditor.loader.ts ), TinyMCE skin assets Affected Data All user sessions; potential for full session compromise Description: The CKEditor screen loads all editor assets from //cdn.ckeditor.com/4.6.2/full-all/ using a protocol-relative URL (which resolves to HTTP on non-HTTPS pages). No Subresource Integrity (SRI) hash is applied to the CDN script tag. If the CKEditor CDN is compromised or the CDN delivery is intercepted (e.g., via BGP hijacking or a CDN provider breach), an attacker could serve a modified version of the CKEditor library containing malicious JavaScript that executes in every user's browser session. The TinyMCE component similarly loads skin assets from a path that assumes the library is globally available, with no integrity verification. The protocol-relative URL // cdn.ckeditor.com/... will load over HTTP when the application is served from an HTTP origin, enabling trivial man-in-the-middle injection. 2. 3. 4. 5. Security Audit Report Security Audit Report Page 11 of 38

-- 11 of 38 --

Evidence: CKEditor screen documentation: "The CDN URL uses a protocol-relative format ( // cdn.ckeditor.com/... ) rather than an explicit https:// scheme." TinyMCE screen documentation: "Relying on a global variable rather than an ES module import means the library's integrity cannot be verified via Subresource Integrity (SRI) unless the script tag in index.html includes an integrity attribute." Attack Scenario: An attacker who compromises the CKEditor CDN (or performs a BGP hijack of the CDN's IP range) serves a modified ckeditor.js that includes a keylogger. Every user who opens the CKEditor screen has their keystrokes captured and exfiltrated to the attacker's server. Because the script runs in the application's origin, it has full access to cookies, localStorage, and the DOM. Remediation: Replace the CDN-loaded CKEditor with the npm package ( ckeditor is already in package.json ) and bundle it with the application, eliminating the CDN dependency entirely. If CDN loading is retained, change the protocol-relative URL to an explicit https:// URL and add an integrity attribute with the SHA-384 hash of the expected file: and and confirming neither executes. Source Evidence: Tiny Mce ( /@theme/components/tiny-mce ), Tiny Mce ( /editors/tiny-mce ) SEC-005: Route-Guard-Only Access Control — No Defense-in-Depth at Component Level Field Value Severity Medium OWASP Category A01: Broken Access Control CWE CWE-284: Improper Access Control AVSV Requirement V4.1.1 — Verify that the application enforces access control rules on a trusted service layer Component All 100 documented screens Affected Data All application data and functionality Description: Every documented screen explicitly states that access control is "delegated entirely to Angular route guards" with no component-level enforcement. While route guards are the correct primary mechanism in Angular, the complete absence of any secondary enforcement means that if a route guard is misconfigured, bypassed (e.g., via a direct component instantiation in a test harness or a future lazy-loaded module that forgets to apply the guard), or if the guard logic contains a bug, there is no fallback. Screens handling sensitive e- commerce data (Country Orders, Visitors Analytics, Smart Table, Security Cameras) are particularly exposed. This is a defense-in-depth gap rather than a direct vulnerability, but it elevates the impact of any guard misconfiguration. 2. 3. 4. Security Audit Report Security Audit Report Page 14 of 38

-- 14 of 38 --

Evidence: Representative example from Dashboard screen documentation, Section 2: "Access control is expected to be enforced at the routing level via Angular route guards... The component itself performs no internal authorization checks." This pattern is repeated identically across all 100 screens. Attack Scenario: A developer adds a new lazy-loaded feature module and forgets to apply the AuthGuard to the module's routes. Because no component-level check exists, the new routes are immediately accessible to unauthenticated users, exposing all data those components load. Remediation: For screens handling sensitive data (e-commerce analytics, smart table, security cameras, dashboard), add a secondary check using Nebular's NbAuthService.isAuthenticated() in ngOnInit and redirect to login if the check fails. Establish a code review checklist item: "Does this route have a canActivate guard applied?" for all new route definitions. Add an integration test that verifies unauthenticated requests to protected routes are redirected to the login page. Verify the fix by attempting to access a protected route without a valid session and confirming the redirect occurs. Source Evidence: All 100 screens SEC-006: Google Maps API Key Exposed Client-Side Without Documented Domain Restriction Field Value Severity Medium OWASP Category A05: Security Misconfiguration CWE CWE-522: Insufficiently Protected Credentials AVSV Requirement V14.2.2 — Verify that the application does not use client-side technologies with known security vulnerabilities Component Gmaps ( /maps/gmaps ), Search ( /maps/search-map/search ) Affected Data Google Maps API quota; potential financial exposure 1. 2. 3. 4. Security Audit Report Security Audit Report Page 15 of 38

-- 15 of 38 --

Description: The Gmaps screen and the Search screen both use the Google Maps JavaScript API. The API key is a client-side credential that is inherently visible in the browser's network requests and source code. The documentation notes: "The Google Maps API key is expected to be configured at the application level... not within this component." No documentation confirms that HTTP referrer restrictions or API restrictions are configured in the Google Cloud Console. Without domain restrictions, the API key can be extracted from the application and used by third parties to consume the application's Maps quota, potentially incurring significant financial charges or causing service disruption. Evidence: Gmaps screen documentation, Section 14: "The Google Maps API key is a client-side credential that is inherently visible in the browser's network requests and source code. API key restrictions (HTTP referrer restrictions, API restrictions) should be configured in the Google Cloud Console to prevent unauthorized use — this is an infrastructure concern outside this component." Attack Scenario: An attacker extracts the Google Maps API key from the application's network requests and uses it to make millions of geocoding or directions API calls, exhausting the application's quota and generating unexpected charges on the billing account. Remediation: In the Google Cloud Console, navigate to the API key settings and add HTTP referrer restrictions limiting the key to your application's domain(s) (e.g., https://yourdomain.com/* ). Apply API restrictions to limit the key to only the specific Google APIs used (Maps JavaScript API, Places API). Set up billing alerts in Google Cloud to notify when usage exceeds expected thresholds. Verify the restriction by attempting to use the key from a different domain and confirming it is rejected. Source Evidence: Gmaps ( /maps/gmaps ), Search ( /maps/search-map/search ) SEC-007: Unsanitized External Input Passed to Service Layer (Country Orders Map) 1. 2. 3. 4. Security Audit Report Security Audit Report Page 16 of 38

-- 16 of 38 --

Field Value Severity Medium OWASP Category A03: Injection CWE CWE-20: Improper Input Validation AVSV Requirement V5.1.3 — Verify that all input is validated, sanitized, and filtered Component CountryOrdersMapComponent , CountryOrdersComponent Affected Data Country orders data; potential for unexpected API behavior Description: The CountryOrdersMapComponent emits a selectEvent containing a country name string derived from feature.properties.name in the GeoJSON data. The parent CountryOrdersComponent passes this string directly to countryOrderService.getCountriesCategoriesData(countryName) without any sanitization or whitelist validation. The documentation notes: "The concrete service implementation should validate or whitelist country identifiers before using them in any HTTP request." While the GeoJSON source is a bundled static asset (low risk), the pattern of passing unvalidated strings from event emitters to service calls is architecturally fragile. If the GeoJSON source were ever changed to a dynamic endpoint, this would become a direct injection vector. Evidence: Country Orders screen documentation, Section 14: "The countryName string received from the map's selectEvent is passed directly to countryOrderService.getCountriesCategoriesData(countryName) and bound to the chart's [countryName] input without sanitization." Attack Scenario: If the GeoJSON asset is replaced with a dynamically fetched file (e.g., from a CDN that is compromised), an attacker could inject a country name containing SQL injection payloads or path traversal sequences that are passed to the backend service. Remediation: In CountryOrdersComponent.selectCountryById() , validate the received country name against a known whitelist of valid country names before passing it to the service. In the concrete CountryOrderData service implementation, apply server-side validation of the country parameter before using it in any database query or HTTP request. 1. 2. Security Audit Report Security Audit Report Page 17 of 38

-- 17 of 38 --

Verify the fix by passing an unexpected string (e.g., '; DROP TABLE orders; -- ) as the country name and confirming it is rejected. Source Evidence: Country Orders ( /e-commerce/country-orders ), Map ( /e-commerce/country- orders/map ) SEC-008: Missing rel="noopener noreferrer" on target="_blank" Links Field Value Severity Low OWASP Category A05: Security Misconfiguration CWE CWE-1022: Use of Web Link to Untrusted Target with window.opener Access AVSV Requirement V14.4.6 — Verify that the application does not use dangerous HTML features Component FooterComponent ( ngx-footer ) Affected Data Application window object; potential for reverse tabnapping Description: The FooterComponent renders five anchor elements with target="_blank" (the Akveo attribution link and four social media icon links). None of these anchors include rel="noopener noreferrer" . Without rel="noopener" , the opened page can access the opener's window object via window.opener , enabling reverse tabnapping attacks where the opened page redirects the original tab to a phishing page. Modern browsers mitigate this by default for cross-origin links, but explicit rel="noopener noreferrer" is still required for full cross-browser protection and is a documented best practice. Evidence: Footer screen documentation, Section 14: "The component uses target='_blank' on all anchor links without a corresponding rel='noopener noreferrer' attribute. This is a known security concern." Attack Scenario: A user clicks the Akveo attribution link. The opened page (if compromised) calls window.opener.location = 'https://phishing-site.com/fake-login' , redirecting the original application tab to a phishing page while the user is reading the opened content. 3. Security Audit Report Security Audit Report Page 18 of 38

-- 18 of 38 --

Remediation: Add rel="noopener noreferrer" to all five anchor elements in footer.component.html . Establish a linting rule (e.g., via eslint-plugin-jsx-a11y or a custom Angular ESLint rule) that flags target="_blank" without rel="noopener" . Verify the fix by inspecting the rendered HTML and confirming the rel attribute is present. Source Evidence: Footer ( /@theme/components/footer ) SEC-009: High-Frequency Polling (200 ms) Without Rate Limiting or Circuit Breaker Field Value Severity Low OWASP Category A05: Security Misconfiguration CWE CWE-400: Uncontrolled Resource Consumption AVSV Requirement V11.1.4 — Verify that the application has sufficient anti-automation controls Component EarningCardFrontComponent ( ngx-earning-card-front ) Affected Data Backend API availability; potential for self-inflicted DoS Description: The EarningCardFrontComponent implements a polling loop using interval(200) — firing 5 requests per second — to update the live earnings chart. No rate limiting, circuit breaker, exponential backoff, or request cancellation (beyond switchMap 's in-flight cancellation) is implemented. The documentation acknowledges: "The 200ms polling interval is appropriate only for mock/in-memory data. If this component is ever connected to a real backend, this interval would need to be significantly increased or replaced with a WebSocket/SSE approach." If this component is deployed against a real API, it would generate 300 requests per minute per active user, which could exhaust API rate limits, degrade backend performance, and constitute a self-inflicted denial of service. Evidence: Front Side ( /e-commerce/earning-card/front-side ) documentation, Section 12: "The 200ms polling interval is appropriate only for mock/in-memory data." 1. 2. 3. Security Audit Report Security Audit Report Page 19 of 38

-- 19 of 38 --

Attack Scenario: With 100 concurrent users on the earning card screen, the application generates 30,000 API requests per minute to the earnings endpoint. The backend rate limiter triggers, causing 429 responses for all users, effectively taking the earnings feature offline. Remediation: Replace the interval(200) polling with a WebSocket or Server-Sent Events connection for real-time data. If polling is retained, increase the interval to a minimum of 5,000 ms (5 seconds) and add exponential backoff on error responses. Implement a circuit breaker: after 3 consecutive errors, pause polling for 30 seconds before retrying. Verify the fix by monitoring network requests in browser DevTools and confirming the request rate is within acceptable limits. Source Evidence: Front Side ( /e-commerce/earning-card/front-side ) SEC-010: ngOnDestroy Bug — Memory Leak in Progress Section Component Field Value Severity Low OWASP Category A05: Security Misconfiguration CWE CWE-401: Missing Release of Memory after Effective Lifetime AVSV Requirement V11.1.6 — Verify that the application does not have resource leaks Component ECommerceProgressSectionComponent ( ngx-progress-section ) Affected Data Browser memory; potential for degraded performance in long-running sessions Description: The ECommerceProgressSectionComponent contains a confirmed bug in its ngOnDestroy lifecycle hook: this.alive = true is set instead of this.alive = false . This means the takeWhile(() => this.alive) operator never receives a false value, so the RxJS 1. 2. 3. 4. Security Audit Report Security Audit Report Page 20 of 38

-- 20 of 38 --

subscription to StatsProgressBarData.getProgressInfoData() is never unsubscribed. If the component is created and destroyed repeatedly (e.g., in a tabbed layout or via route navigation), each instance leaves a dangling subscription, causing a memory leak that accumulates over the session lifetime. Evidence: Progress Section screen documentation, Section 17: "Critical Bug — ngOnDestroy sets alive = true instead of false ... The takeWhile(() => this.alive) operator is designed to unsubscribe from the observable when alive becomes false . However, ngOnDestroy sets it to true (its already-initialized value), meaning the predicate never changes and the subscription is never terminated." Attack Scenario: A user navigates between dashboard tabs repeatedly over a long session. Each navigation creates and destroys the Progress Section component, but each instance leaves a live subscription. After 50 navigations, 50 subscriptions are active, each potentially making periodic service calls, degrading browser performance and potentially causing unexpected data mutations. Remediation: Change this.alive = true to this.alive = false in the ngOnDestroy method of ECommerceProgressSectionComponent . Consider migrating to the takeUntil(this.destroy$) pattern with a Subject for more reliable subscription management. Verify the fix by adding a unit test that creates and destroys the component multiple times and confirms no active subscriptions remain after destruction. Source Evidence: Progress Section ( /e-commerce/progress-section ) SEC-011: Unguarded ngOnDestroy Media Query Subscription (Security Cameras) 1. 2. 3. Security Audit Report Security Audit Report Page 21 of 38

-- 21 of 38 --

Field Value Severity Low OWASP Category A05: Security Misconfiguration CWE CWE-401: Missing Release of Memory after Effective Lifetime AVSV Requirement V11.1.6 — Verify that the application does not have resource leaks Component SecurityCamerasComponent ( ngx-security-cameras ) Affected Data Browser memory; potential for degraded performance Description: The SecurityCamerasComponent subscribes to themeService.onMediaQueryChange() in ngOnInit without applying takeUntil(this.destroy$) or any other unsubscription mechanism. The documentation explicitly identifies this: "The themeService.onMediaQueryChange() subscription in ngOnInit does NOT use takeUntil(this.destroy$) ... This subscription will persist after the component is destroyed, causing a memory leak." Unlike the Progress Section bug (SEC-010), this is a missing unsubscription rather than a wrong value, but the effect is the same: dangling subscriptions accumulate on repeated navigation. Evidence: Security Cameras screen documentation, Section 17: "Memory Leak — Unguarded Media Query Subscription: The themeService.onMediaQueryChange() subscription in ngOnInit does not use takeUntil(this.destroy$) ." Attack Scenario: Same as SEC-010 — repeated navigation to the Security Cameras screen leaves accumulating subscriptions that fire on every viewport resize, degrading performance over time. Remediation: Add takeUntil(this.destroy$) to the themeService.onMediaQueryChange() subscription chain in SecurityCamerasComponent . Ensure this.destroy$.next() and this.destroy$.complete() are called in ngOnDestroy . Verify the fix with a unit test confirming no active subscriptions remain after component destruction. Source Evidence: Security Cameras ( /dashboard/security-cameras ) SEC-012: CKEditor Protocol-Relative CDN URL (HTTP Downgrade Risk) 1. 2. 3. Security Audit Report Security Audit Report Page 22 of 38

-- 22 of 38 --

Field Value Severity Low OWASP Category A05: Security Misconfiguration CWE CWE-319: Cleartext Transmission of Sensitive Information AVSV Requirement V9.1.1 — Verify that TLS is used for all connections Component CKEditor loader ( ckeditor.loader.ts ) Affected Data CKEditor script integrity; potential for script injection on HTTP origins Description: The CKEditor loader sets window['CKEDITOR_BASEPATH'] to //cdn.ckeditor.com/ 4.6.2/full-all/ using a protocol-relative URL. On any page served over HTTP (rather than HTTPS), this resolves to http://cdn.ckeditor.com/... , loading the editor assets over an unencrypted connection. This enables man-in-the-middle attacks where an attacker on the same network can intercept and modify the CKEditor JavaScript before it reaches the browser. This is distinct from the SRI issue (SEC-003) and specifically concerns the transport security of the CDN request. Evidence: CKEditor screen documentation, Section 17: "Protocol-Relative URL: A URL beginning with // (no scheme), which inherits the protocol ( http: or https: ) from the current page. Considered a legacy pattern." Attack Scenario: A user accesses the application over HTTP (e.g., on a corporate intranet without HTTPS). An attacker on the same network intercepts the http://cdn.ckeditor.com/ckeditor.js request and injects a keylogger into the response. Remediation: Change the CDN URL in ckeditor.loader.ts from //cdn.ckeditor.com/4.6.2/full-all/ to https://cdn.ckeditor.com/4.6.2/full-all/ . Enforce HTTPS for the entire application via HSTS headers and redirect all HTTP traffic to HTTPS at the server/CDN level. Verify the fix by inspecting network requests and confirming all CDN assets are loaded over HTTPS. Source Evidence: Ckeditor ( /editors/ckeditor ) 1. 2. 3. Security Audit Report Security Audit Report Page 23 of 38

-- 23 of 38 --

Finding Inventory Security Audit Report Security Audit Report Page 24 of 38

-- 24 of 38 --

ID Screen Title Severity OWASP CWE AVSV Rem Phas SEC-001 All 100 screens No Security Logging or Monitoring Instrumentation High A09 CWE-778 V7.1.1 Shor SEC-002 Global (package.json) Severely Outdated Dependencies with Known Vulnerabilities High A06 CWE-1104 V14.2.1 Shor SEC-003 CKEditor, TinyMCE CDN Asset Loading Without Subresource Integrity High A08 CWE-353 V14.2.3 Shor SEC-004 TinyMCE (/ @theme, / editors) TinyMCE Emits Raw Unsanitized HTML to Parent Components High A03 CWE-79 V5.3.3 Shor SEC-005 All 100 screens Route-Guard-Only Access Control — No Defense-in-Depth Medium A01 CWE-284 V4.1.1 Med Term SEC-006 Gmaps, Search Map Google Maps API Key Exposed Without Documented Domain Restriction Medium A05 CWE-522 V14.2.2 Med Term SEC-007 Country Orders, Map Unsanitized External Input Passed to Service Layer Medium A03 CWE-20 V5.1.3 Med Term SEC-008 Footer Missing rel="noopener noreferrer" on target="_blank" Links Low A05 CWE-1022 V14.4.6 Back SEC-009 Earning Card Front Side High-Frequency Polling Without Rate Limiting Low A05 CWE-400 V11.1.4 Back SEC-010 Progress Section ngOnDestroy Bug — Memory Leak Low A05 CWE-401 V11.1.6 Back Security Audit Report Security Audit Report Page 25 of 38

-- 25 of 38 --

ID Screen Title Severity OWASP CWE AVSV Rem Phas SEC-011 Security Cameras Unguarded Media Query Subscription Memory Leak Low A05 CWE-401 V11.1.6 Back SEC-012 CKEditor Protocol-Relative CDN URL (HTTP Downgrade Risk) Low A05 CWE-319 V9.1.1 Back Needs Verification The following items are inferred from patterns in the documentation rather than directly evidenced. They are NOT counted in severity totals and are NOT included in the Remediation Roadmap. Each requires verification before acting. NV-001: Content Security Policy (CSP) Configuration Unknown Basis for inference: No CSP headers are mentioned in any of the 100 screen documentation files or in the PROJECT CONFIG files provided. The application loads external scripts (Google Maps, CKEditor CDN, TinyMCE) that would require CSP script-src directives. Why not a confirmed finding: CSP is typically configured at the server/CDN layer (nginx, Apache, Cloudflare), not in Angular component code. Its absence from the documentation does not confirm its absence from the deployment. Verification action: [Not documented — WHO: DevOps team; WHAT: Is a Content Security Policy header configured on the application's web server or CDN? If so, what are the script-src , connect- src , and frame-src directives?; WHERE: Insert confirmed CSP configuration into SEC-003 remediation section and create a new finding if CSP is absent] • • • Security Audit Report Security Audit Report Page 26 of 38

-- 26 of 38 --

NV-002: Authentication Guard Implementation and Coverage Basis for inference: All 100 screens state that authentication is "delegated to Angular route guards" but no route guard source code is provided. The @nebular/auth package (version 11.0.1) is present in the PROJECT MANIFEST, suggesting Nebular Auth is used. Why not a confirmed finding: The presence of @nebular/auth in the manifest suggests guards exist; their absence from the documentation does not confirm they are missing. Verification action: [Not documented — WHO: Lead developer; WHAT: Which Angular route guards are applied to the /dashboard , /e-commerce , /tables , /maps , /charts , / editors , /forms , /modal-overlays , /extra-components , and /ui-features route groups? Are all sensitive routes covered?; WHERE: Insert confirmed guard coverage into SEC-005 finding and update severity if gaps are found] NV-003: HTTPS Enforcement and HSTS Configuration Basis for inference: The CKEditor protocol-relative URL (SEC-012) implies the application may be accessible over HTTP. No HTTPS enforcement or HSTS configuration is documented. Why not a confirmed finding: HTTPS enforcement is an infrastructure concern not visible in Angular component code. Verification action: [Not documented — WHO: DevOps team; WHAT: Is HTTPS enforced for all application traffic? Is an HSTS header configured with a max-age of at least 31536000?; WHERE: Insert confirmed HTTPS/HSTS status into SEC-012 remediation section] NV-004: Server-Side HTML Sanitization for TinyMCE Output Basis for inference: The TinyMCE component emits raw HTML (SEC-004). Whether the backend sanitizes this HTML before storage and re-rendering is unknown from the frontend documentation. Why not a confirmed finding: The backend implementation is outside the scope of this frontend documentation review. Verification action: [Not documented — WHO: Backend developer; WHAT: Is HTML content submitted from the TinyMCE editor sanitized server-side before storage? Which sanitization library is used?; WHERE: Insert confirmed sanitization status into SEC-004 remediation section; if no server-side sanitization exists, escalate SEC-004 to Critical] • • • • • • • • • Security Audit Report Security Audit Report Page 27 of 38

-- 27 of 38 --

AVSV Compliance Summary Chapter Topic Requirements Assessed Pass Fail N/ A Compliance V1 Architecture 3 1 2 0 33% V2 Authentication 2 1 0 1 Limited Assessment V3 Session Management 2 1 0 1 Limited Assessment V4 Access Control 3 1 2 0 33% V5 Validation 4 2 2 0 50% V7 Error Handling 3 0 3 0 0% V8 Data Protection 3 2 1 0 67% V9 Communication 2 1 1 0 50% V10 Malicious Code 2 1 1 0 50% V11 Business Logic 4 2 2 0 50% V12 Files & Resources 1 1 0 0 100% V13 API 2 1 1 0 50% V14 Configuration 5 1 4 0 20% Note: V2 and V3 are marked "Limited Assessment" because authentication and session management are implemented via @nebular/auth (confirmed present in PROJECT MANIFEST) but no auth screen source code was included in the assessment scope. The compliance percentages above reflect only what could be assessed from the provided documentation. Security Audit Report Security Audit Report Page 28 of 38

-- 28 of 38 --

Remediation Roadmap Phase 1: Immediate (0–7 days) — No Critical findings identified No Critical-severity findings were identified in this assessment. Phase 2: Short-Term (1–4 weeks) — All High findings SEC-001: Instrument security logging across all screens — install @sentry/angular or equivalent, configure DSN, add error boundary. Effort: 3–5 days SEC-002: Audit and upgrade outdated dependencies — run npm audit , prioritize CKEditor 4→5 migration, Bootstrap 4→5, Angular 15→18. Effort: 5–10 days SEC-003: Eliminate CDN loading for CKEditor and TinyMCE — migrate to npm package imports, add SRI hashes if CDN is retained. Effort: 2–3 days SEC-004: Implement TinyMCE output sanitization — add DOMPurify to the TinyMCE component's editorKeyup handler and enforce server-side sanitization. Effort: 1–2 days Phase 2 Total Effort Estimate: 11–20 developer-days Phase 3: Medium-Term (1–3 months) — All Medium findings SEC-005: Add component-level authentication checks to sensitive screens (e-commerce, dashboard, tables) — implement NbAuthService.isAuthenticated() guard in ngOnInit for high-value screens. Effort: 3–5 days SEC-006: Restrict Google Maps API key — configure HTTP referrer and API restrictions in Google Cloud Console. Effort: 0.5 days SEC-007: Add country name whitelist validation in CountryOrdersComponent — validate against known ISO country codes before passing to service. Effort: 0.5 days Phase 3 Total Effort Estimate: 4–6 developer-days • • • • • • • Security Audit Report Security Audit Report Page 29 of 38

-- 29 of 38 --

Phase 4: Backlog — Low and Info findings SEC-008: Add rel="noopener noreferrer" to footer links — one-line template fix. Effort: 0.5 hours SEC-009: Replace 200 ms polling with WebSocket or increase interval to ≥5 s with backoff. Effort: 1–2 days SEC-010: Fix ngOnDestroy bug in ECommerceProgressSectionComponent — change true to false . Effort: 0.5 hours SEC-011: Add takeUntil(this.destroy$) to media query subscription in SecurityCamerasComponent . Effort: 1 hour SEC-012: Change CKEditor CDN URL from protocol-relative to explicit https:// . Effort: 0.5 hours Phase 4 Total Effort Estimate: 2–3 developer-days Positive Security Patterns Pattern 1: Angular Template Auto-Escaping Applied Consistently Where: All 100 screens Standard Alignment: OWASP ASVS V5.3.3 — Output encoding is context-appropriate; OWASP Top 10 A03 mitigation Description: Every screen that renders dynamic data uses Angular's standard template binding syntax ( {{ }} interpolation and [property] bindings), which automatically HTML-encodes interpolated values. No screen in the assessment uses [innerHTML] with unsanitized data or calls DomSanitizer.bypassSecurityTrustHtml() directly. This provides a strong baseline XSS defense across the entire application. Recommendation: Maintain this pattern by adding an ESLint rule ( @angular-eslint/template/no-any-binding or a custom rule) that flags [innerHTML] usage for mandatory security review. Pattern 2: Consistent RxJS Subscription Lifecycle Management Where: Dashboard, Country Orders, Header, Traffic, Charts Panel, Visitors Analytics, and approximately 60 other screens • • • • • • • • • • Security Audit Report Security Audit Report Page 30 of 38

-- 30 of 38 --

Standard Alignment: OWASP ASVS V11.1.6 — Resource leak prevention; NIST SP 800-53 SI-10 Description: The vast majority of screens that use RxJS subscriptions correctly implement the takeWhile(() => this.alive) pattern (or takeUntil(this.destroy$) ) combined with ngOnDestroy cleanup. This prevents memory leaks from dangling subscriptions in long-running single- page application sessions. The two exceptions (SEC-010, SEC-011) are documented bugs rather than systemic failures. Recommendation: Standardize on the takeUntil(this.destroy$) pattern (using Angular 16+ DestroyRef or a Subject ) across all screens for consistency and to eliminate the takeWhile predicate-evaluation overhead. Pattern 3: Abstract Service Pattern for Data Access Where: Dashboard (SolarData), Country Orders (CountryOrderData), Contacts (UserData), Temperature (TemperatureHumidityData), and approximately 20 other screens Standard Alignment: OWASP ASVS V1.1.2 — Separation of concerns; NIST SP 800-53 SA-8 Description: The application consistently uses Angular abstract classes as DI tokens for data services, cleanly separating the UI layer from the data access layer. This pattern makes it straightforward to swap mock implementations for real API-backed implementations, and it means that server-side security controls (authentication headers, input validation, rate limiting) can be applied centrally in the concrete service implementations without modifying any UI component. Recommendation: Extend this pattern to ensure all concrete service implementations include HTTP interceptors that attach authentication tokens and validate response shapes before passing data to components. Pattern 4: Nebular Auth Integration for Authentication Where: Application-wide (confirmed by @nebular/auth: 11.0.1 in PROJECT MANIFEST) Standard Alignment: OWASP ASVS V2.1 — Password security; V3.1 — Session management; OWASP Top 10 A07 mitigation Description: The application uses @nebular/auth , a well-maintained authentication library that provides token management, login/logout flows, and route guard integration. Using a dedicated auth library rather than custom authentication code reduces the risk of implementation errors in security-critical flows. • • • • • • • • • • Security Audit Report Security Audit Report Page 31 of 38

-- 31 of 38 --

Recommendation: Verify that @nebular/auth is configured with appropriate token expiry, refresh token rotation, and secure storage (avoid localStorage for tokens; prefer sessionStorage or HTTP-only cookies). Pattern 5: Nebular Security Module Present Where: Application-wide (confirmed by @nebular/security: 11.0.1 in PROJECT MANIFEST) Standard Alignment: OWASP ASVS V4.1 — Access control; NIST SP 800-53 AC-3 Description: The @nebular/security package is present in the dependency manifest. This module provides role-based access control (RBAC) primitives for Angular applications, including NbAclService and NbSecurityModule . Its presence indicates the application has the infrastructure to implement fine-grained role-based access control, even though no component-level role checks were observed in the 100 documented screens. Recommendation: Leverage @nebular/security 's NbAclService to add component-level authorization checks to sensitive screens (e-commerce analytics, smart table, security cameras), addressing SEC-005 without requiring custom authorization code. • • • • • Security Audit Report Security Audit Report Page 32 of 38

-- 32 of 38 --

Glossary Security Terms Security Audit Report Security Audit Report Page 33 of 38

-- 33 of 38 --

Term Definition AVSV (OWASP Application Security Verification Standard) A framework of security requirements for designing, developing, and testing secure web applications. Version 4.0.3 used in this assessment. CSRF (Cross-Site Request Forgery) An attack that tricks a user's browser into making an unintended request to a web application where the user is authenticated. CSP (Content Security Policy) An HTTP response header that instructs browsers to restrict which resources (scripts, styles, images) can be loaded, mitigating XSS and data injection attacks. CVE (Common Vulnerabilities and Exposures) A publicly disclosed cybersecurity vulnerability with a unique identifier (e.g., CVE-2019-8331). DAST (Dynamic Application Security Testing) Security testing performed against a running application, as opposed to source code review. Defense-in-Depth A security strategy that applies multiple layers of controls so that if one layer fails, others remain. HSTS (HTTP Strict Transport Security) An HTTP response header that instructs browsers to only connect to the server over HTTPS, preventing protocol downgrade attacks. IDOR (Insecure Direct Object Reference) A type of access control vulnerability where an attacker can access objects (files, database records) by manipulating a reference (e.g., an ID in a URL). Memory Leak A condition where a program allocates memory but fails to release it when no longer needed, causing gradual resource exhaustion. Reverse Tabnapping An attack where a page opened via target="_blank" uses window.opener to redirect the original tab to a malicious page. SAST (Static Application Security Testing) Security testing performed by analyzing source code without executing it. SRI (Subresource Integrity) A browser security feature that allows verification of fetched resources (scripts, stylesheets) using a cryptographic hash. Stored XSS A type of XSS where malicious script is stored on the server and executed when other users view the affected content. Security Audit Report Security Audit Report Page 34 of 38

-- 34 of 38 --

Term Definition XSS (Cross-Site Scripting) An attack where malicious scripts are injected into web pages viewed by other users. OWASP Top 10 Categories Category Definition A01: Broken Access Control Failures in enforcing restrictions on what authenticated users are allowed to do. A02: Cryptographic Failures Failures related to cryptography that expose sensitive data. A03: Injection Hostile data sent to an interpreter as part of a command or query (SQL, XSS, etc.). A04: Insecure Design Missing or ineffective control design that cannot be fixed by correct implementation alone. A05: Security Misconfiguration Insecure default configurations, incomplete configurations, or misconfigured security controls. A06: Vulnerable & Outdated Components Using components with known vulnerabilities or that are no longer maintained. A07: Identification & Authentication Failures Weaknesses in authentication and session management. A08: Software & Data Integrity Failures Code and infrastructure that does not protect against integrity violations. A09: Security Logging & Monitoring Failures Insufficient logging, monitoring, and incident response. A10: Server-Side Request Forgery (SSRF) Forcing the server to make requests to unintended locations. Security Audit Report Security Audit Report Page 35 of 38

-- 35 of 38 --

CWE Weakness Types CWE Name CWE-20 Improper Input Validation CWE-79 Improper Neutralization of Input During Web Page Generation (XSS) CWE-284 Improper Access Control CWE-319 Cleartext Transmission of Sensitive Information CWE-353 Missing Support for Integrity Check CWE-400 Uncontrolled Resource Consumption CWE-401 Missing Release of Memory after Effective Lifetime CWE-522 Insufficiently Protected Credentials CWE-778 Insufficient Logging CWE-1022 Use of Web Link to Untrusted Target with window.opener Access CWE-1104 Use of Unmaintained Third-Party Components Security Audit Report Security Audit Report Page 36 of 38

-- 36 of 38 --

AVSV Chapter Names Chapter Name V1 Architecture, Design and Threat Modeling V2 Authentication V3 Session Management V4 Access Control V5 Validation, Sanitization and Encoding V7 Error Handling and Logging V8 Data Protection V9 Communication V10 Malicious Code V11 Business Logic V12 Files and Resources V13 API and Web Service V14 Configuration Security Audit Report Security Audit Report Page 37 of 38

-- 37 of 38 --

Acronyms Acronym Expansion ACF Advanced Content Filter (TinyMCE/CKEditor feature) API Application Programming Interface CDN Content Delivery Network CSP Content Security Policy CSRF Cross-Site Request Forgery CVE Common Vulnerabilities and Exposures DAST Dynamic Application Security Testing DI Dependency Injection (Angular) DOM Document Object Model HSTS HTTP Strict Transport Security IDOR Insecure Direct Object Reference PII Personally Identifiable Information RBAC Role-Based Access Control SAST Static Application Security Testing SPA Single-Page Application SRI Subresource Integrity SSRF Server-Side Request Forgery TLS Transport Layer Security WYSIWYG What You See Is What You Get XSS Cross-Site Scripting Security Audit Report Security Audit Report Page 38 of 38

-- 38 of 38 --