HTML input accepted and rendered in Project Display Name – expected behavior and recommended mitigat

SonarQube Server / Community Build
, , ,
1

Hello SonarSource Community Team,

We are using SonarQube Community / Developer Build deployed via Docker in an internal environment.

During a recent security assessment, it was observed that the Project Display Name field accepts HTML input (for example <h1>Test</h1>) and renders it in the UI. This behavior was flagged by the security team as Improper Input Validation (CWE‑20) / UI‑level HTML injection.

We understand that:

  • SonarQube is an administrative DevOps tool

  • Access is intended for authenticated and trusted users

  • SonarQube is commonly secured via authentication, access control, and reverse‑proxy hardening

We would appreciate clarification on the following points:

  1. Is accepting and rendering HTML input in administrative UI fields (such as Project Display Name) considered expected behavior in SonarQube?

  2. For such UI‑level findings, is the recommended security approach to mitigate risk by:

    • enforcing authentication,

    • restricting access to trusted users,

    • and applying reverse‑proxy controls (e.g., CSP, security headers), rather than modifying or sanitizing the SonarQube UI?

  3. Are there any official hardening or best‑practice recommendations to address UI input handling in SonarQube?

For context, in our setup:

  • SonarQube is not publicly exposed

  • Anonymous access is disabled

  • Access is restricted to internal users only

Thank you for your guidance.**

**

2

Hi,

Welcome to the community and thanks for this report!

What version are you using? Check the page footer if you’re not sure. And can you describe the path to the input?

 
Thx,
Ann

3

Hi Ann,

Thank you for your response.

We are using SonarQube Community Build v25.6.0.109173 (version confirmed from the page footer).

Path to the input:

  1. Log in to SonarQube with an authenticated user

  2. Go to Projects

  3. Create a new project or open an existing project

  4. In the Project Display Name field, enter HTML input (for example: <h1>Test</h1>)

  5. Save the project

  6. The entered HTML is rendered as HTML in the Projects list / project page

For context, our SonarQube instance is deployed via Docker, anonymous access is disabled, and it is accessible only to internal authenticated users.

Please let us know if any additional details are required.

Thanks,
Salma

4

Hi Salma,

Only the latest version of SonarQube Community Build is considered active, so you’ll need to update and see if the situation is still replicable before we can help you.

Your update path is:

25.6 → 26.1 → 26.2

You may find these resources helpful:

If you have questions about upgrading, feel free to open a new thread for that here.

If your error persists after update, please come back to us.

 
Thx,
Ann

5

Hi Ann and Team,

We reviewed this behavior on SonarQube Enterprise Edition v26.2. The tool allows HTML-like input (e.g. <h1>Test</h1>) in the project name field; however, the input is safely escaped and treated as plain text. The HTML is neither rendered nor executed in the UI.

we are able to create project with this name <h1>Test</h1>.

Thanks,
salma.

6

Hi,

Thanks for the update.

Going back to the remaining question:

I think this is always the case, wouldn’t you say?

 
Ann

7

Hi Team,

Thank you for your detailed explanation — it was very helpful.
To ensure we address the observation correctly, we just want to confirm our understanding. Based on our analysis and your guidance, the behavior where SonarQube accepts HTML‑like values in the project name (while safely escaping and not executing them) is an intended UI‑level behavior rather than a backend input‑validation requirement by changing configurations.

Could you please confirm that, from a SonarSource perspective, this should indeed be considered UI behavior by design.

This confirmation will help us align our response accurately with the team.
Thanks again for your support.
Regards,
Salma

9

Hi Salma,

that’s correct.

Kind regards,