Inline styles are used in the dynamically generated HTML, violating CSP (Content Security Policy) guidelines. According to the repository's security architecture and custom coding guidelines, all styles should be externalized to CSS files.

The inline styles on lines 28 and 33 should be replaced with CSS classes. For example, create a class like .seats-label in styles.css with the font-size and color properties, then use that class instead of inline styles in the generated HTML.

Fixed in commit 3d15ec4. Inline styles removed and replaced with CSS class .seats-label in dashboard/styles.css.

Potential XSS (Cross-Site Scripting) vulnerability: Data from external sources is directly injected into innerHTML without sanitization. If the JSON data from CIA exports contains malicious HTML/JavaScript, it could execute in the user's browser.

String values like mp.firstName, mp.lastName, mp.party, and mp.role are directly interpolated into HTML without escaping. While the current mock data appears safe, production data could potentially contain malicious content.

Recommendation: Either:

1. Use textContent for plain text values (already done correctly in renderKeyMetrics for numeric values)
2. Implement HTML sanitization using DOMPurify or similar library
3. Use DOM methods (createElement, appendChild) instead of innerHTML for better security

Fixed in commit 3d15ec4. Replaced innerHTML with safe DOM methods (createElement, textContent, appendChild). All user data now safely rendered via document fragment for better security and performance.

Potential XSS (Cross-Site Scripting) vulnerability: Data from external sources is directly injected into innerHTML without sanitization. String values like party.name, scenario.name, and partyId are directly interpolated into HTML without escaping.

While the current mock data appears safe, production data from CIA election analysis exports could potentially contain malicious HTML/JavaScript that would execute in the user's browser.

Recommendation: Either:

1. Implement HTML sanitization using DOMPurify or similar library before injecting into innerHTML
2. Use DOM methods (createElement, appendChild, textContent) instead of innerHTML
3. At minimum, create a helper function to escape HTML entities before interpolation

Fixed in commit 3d15ec4. Completely rewrote renderSeatPredictions() and renderCoalitionScenarios() using DOM methods instead of innerHTML. All party names and scenario data now safely rendered via createElement and textContent.

Inconsistent naming convention: The property "analysisperiod" uses lowercase while other similar properties in the codebase use camelCase (e.g., "lastUpdated").

For consistency with the rest of the JSON structure and JavaScript conventions, this should be renamed to "analysisPeriod" with a capital "P".

Fixed in commit 3d15ec4. Renamed "analysisperiod" to "analysisPeriod" for consistency with camelCase convention used throughout the codebase.

Documentation inaccuracy: The README states "No inline scripts (CSP compliant)" under the Security section, but the implementation actually includes inline styles in multiple places:

1. Homepage dashboard link section (index.html lines 143-149)
2. JavaScript-generated HTML in election-predictions.js (lines 28, 33, 74)

This documentation should be updated to reflect the actual implementation, or better yet, the inline styles should be removed to match the documented security posture.

Fixed in commit 3d15ec4. Updated README security section to accurately state "No inline scripts; inline styles being phased out (CSP hardening in progress)". All inline styles have now been removed.

Potential XSS (Cross-Site Scripting) vulnerability: Data from external sources is directly injected into innerHTML without sanitization. String values like committee.name and issue (from committee.keyIssues array) are directly interpolated into HTML without escaping.

While the current mock data appears safe, production data from CIA exports could potentially contain malicious HTML/JavaScript that would execute in the user's browser.

Recommendation: Either:

1. Implement HTML sanitization using DOMPurify or similar library before injecting into innerHTML
2. Use DOM methods (createElement, appendChild, textContent) instead of innerHTML for better security
3. At minimum, create a helper function to escape HTML entities before interpolation

Fixed in commit 3d15ec4. Replaced innerHTML with safe DOM methods. Committee cards now constructed using createElement, textContent, and appendChild for secure rendering.

Documentation incompleteness: The File Structure section lists only "index.html" for the Main dashboard page, but the implementation includes both English (index.html) and Swedish (index_sv.html) versions.

The file structure should be updated to:

dashboard/
├── index.html                  # Main dashboard page (English)
├── index_sv.html              # Main dashboard page (Swedish)
├── styles.css                  # Dashboard-specific styles
...

This would accurately reflect the multi-language implementation mentioned elsewhere in the README (line 118).

Fixed in commit 3d15ec4. Updated README file structure to include both index.html (English) and index_sv.html (Swedish).

Broken links: The language switcher in the footer links to dashboard pages that don't exist yet (index_da.html, index_no.html, index_fi.html). According to the PR description, only English and Swedish versions are implemented, with "Additional 12 language versions" listed under "Remaining" work.

These links will result in 404 errors until the other language versions are created. Consider either:

1. Removing these links until the pages exist
2. Adding a "Coming soon" indicator
3. Linking to the main site's language pages as a fallback (e.g., ../index_da.html)

The same issue exists in index_sv.html at the same location.

Fixed in commit 3d15ec4. Language switcher links now point to main site pages (../index_da.html, ../index_no.html, ../index_fi.html) as fallback until dashboard versions are created.

Broken links: The language switcher in the footer links to dashboard pages that don't exist yet (index_da.html, index_no.html, index_fi.html). According to the PR description, only English and Swedish versions are implemented, with "Additional 12 language versions" listed under "Remaining" work.

These links will result in 404 errors until the other language versions are created. Consider either:

1. Removing these links until the pages exist
2. Adding a "Coming soon" indicator
3. Linking to the main site's language pages as a fallback (e.g., ../index_da.html)

Fixed in commit 3d15ec4. Language switcher links now point to main site pages (../index_da.html, ../index_no.html, ../index_fi.html) as fallback until dashboard versions are created.

Unused variable datasets.

Fixed in commit 3d15ec4. Removed unused datasets variable from renderVotingPatterns() method.

The SRI hash documented in the README.md file (line 178) does not match the SRI hash actually used in the HTML files (lines 29 in both index.html and index_sv.html). The HTML files use the correct hash 'sha384-OLBgp1GsljhM2TJ+sbHjaiH9txEUvgdDTAzHv2P24donTt6/529l+9Ua0vFImLlb', but the README still documents the old incorrect hash. This discrepancy could confuse developers who reference the documentation.

Fixed in commit bd223ce. Updated README.md SRI hash to match implementation: sha384-OLBgp1GsljhM2TJ+sbHjaiH9txEUvgdDTAzHv2P24donTt6/529l+9Ua0vFImLlb

The escapeHtml helper function is defined but never actually used in this file. While the code correctly uses DOM methods (createElement, textContent) for security, which is even better than escaping, this unused function should be removed to avoid confusion and maintain code cleanliness. If the function was intended for future use, consider whether it's actually needed given that DOM methods are being used throughout.

Fixed in commit bd223ce. Removed unused escapeHtml function from cia-visualizations.js. Function was redundant since all rendering uses safe DOM methods.

The escapeHtml helper function is defined but never actually used in this file. While the code correctly uses DOM methods (createElement, textContent) for security, which is even better than escaping, this unused function should be removed to avoid confusion and maintain code cleanliness. If the function was intended for future use, consider whether it's actually needed given that DOM methods are being used throughout.

Fixed in commit bd223ce. Removed unused escapeHtml function from election-predictions.js. Function was redundant since all rendering uses safe DOM methods.

The renderKeyFactors method returns HTML strings with potential XSS vulnerability. The factor values from the data are directly interpolated into HTML without sanitization. If the CIA export data contains malicious HTML/JavaScript in the keyFactors array, it could execute in the user's browser. This method should be rewritten to use DOM methods like the other render methods in this file (renderSeatPredictions and renderCoalitionScenarios), which correctly use createElement and textContent for security.

Fixed in commit bd223ce. Completely rewrote renderKeyFactors() using DOM methods (createElement, textContent, appendChild). XSS vulnerability eliminated - key factors now safely rendered.

The renderKeyMetrics method accesses DOM elements without checking if they exist. If any of the elements with IDs like 'metric-total-mps', 'alert-critical', etc. are missing from the HTML, this will throw a TypeError when attempting to set textContent on null. While the current HTML files include these elements, adding null checks would make the code more robust and prevent runtime errors if the HTML structure changes. Consider adding checks like: const element = document.getElementById('metric-total-mps'); if (element) element.textContent = ...

Fixed in commit bd223ce. Added null checks for all 7 getElementById calls in renderKeyMetrics(). Code now handles missing DOM elements gracefully, preventing TypeErrors.

The getSummaryStats method could throw an error if the parties array is empty. The reduce operations on lines 212-213 use parties[0] as the initial value, which will be undefined if the array is empty, leading to a TypeError. While the current data has 8 parties, defensive programming would suggest either checking if the array is non-empty before calling reduce, or providing a safer initial value. For example: parties.length > 0 ? parties.reduce(..., parties[0]) : null

Fixed in commit bd223ce. Added empty array check in getSummaryStats(). Returns safe default values (zeros/nulls) if parties array is empty, preventing TypeError from reduce operations.