Support UI Customization via Country Configuration (Scripts & CSS Injection)

[ThierryMyshepherd]

We would like to propose a generic and reusable feature for OpenCRVS core to support frontend/UI customization via the country configuration. This would enable countries to inject custom scripts and CSS or link to externally hosted tools

Problem Statement
Currently, implementing UI-level customizations (e.g., adding a feedback form, linking to an external service, or custom styling) often requires a core fork or hardcoded changes. This approach:
Creates technical debt and long-term maintenance challenges.
Complicates upgrades, especially when applying new product releases or hotfixes.
Limits flexibility for countries to respond to specific local needs or regulations.

A flexible frontend/UI customization capability that allows countries to:

• Add custom scripts and CSS
• Include external scripts (e.g., feedback tools, UI components), ideally from a country's private or controlled infrastructure.
• Manage these customisations via the country configuration, rather than hardcoding or forking core.

Related issues: #9712

[euanmillar]

If we enable the capability for any JS that a country chooses on OpenCRVS then there is potentially a dangerous open door that can be exploited. Whatever 3rd party JS library is used could itself be vulnerable to a hacker in order to gain access to the core system and exploit it.

Additionally, any 3rd party JS library that is used would never be included in our penetration tests.

Where we currently enable custom pure JavaScript expressions to be run in OpenCRVS is sandboxed - extremely self-contained in the application, such as constrained to form validation eval() function, where JS has no access to items such as JWT tokens for example. To enable custom JS libraries at the application level could expose the entire application to the custom logic that is added.

If we allow this to pass into core supported code, then we are broadcasting to the community that this back-door (ejecting) approach is an approved way to build whatever a country wants on top of OpenCRVS. We could not adopt that posture and instead advise countries to use the companion app approach or fork OpenCRVS if they wish to customise it like this.

We request specific user-driven feature requests instead of general customisation requests like this.