Unauthenticated access to Badges only in a secure manner

Hello. We use SonarQube here at Indeed - thank you for making such a great product, and would like to request a new feature in SonarQube.

The problem we are trying to solve is to show badges for our projects in Gitlab inside our company.

We can do this, but the default URL requires us to put a token on the URL - an example:


We could turn off “Force user authentication” to prevent us from needing to append the token, but Security clearly indicates this is not recommended and we are very uncomfortable doing this.

We would like an option to “allow unauthenticated access to badges only” permission so that we can use the URL above without needing the token at the end while keeping everything else appropriately secured.

I believe that by making it easier for companies to use badges in a secure manner in their corporate SonarQube instances it would help your customers to integrate more deeply with SonarQube making the relationship more sticky and should be a priority for SonarQube.

Thank you very much for considering our request, please feel free to reach out to me with any questions or comments you may have any time, and thank you very much for producing such a great product that helps us produce better code.

Thank you very much,

Larry Diamond

1 Like

Hey Larry.

Ultimately, what’s the problem with putting a token at the end of the URL? What issue is it causing that wants you to find another solution?

I’d be cautious about any kind of “allow unauthenticated access to badges only” setting – this could pretty quickly leak project keys and metrics.

Thank you very much for getting back to me on this idea.

These image URLs are being shared throughout our firm, and we’re concerned about what the scope of access is for that token at the end of the URL.

Does that token in the URL only provide access to badges? Does that token provide a whole lot more? Does that token provide access to our source code? Once you have the URL for access to the badge, you already have the project key - it’s there in the URL - that’s already leaked once you have the URL.

If there’s an “allow only access to badges” permission, the access can be cleanly tested and appropriately secured. By providing clear text tokens on the URL the access that token gets is unclear and potentially far more than intended.

Does that answer your question?

You can read about badge tokens here – they are scoped so that they can only return metric information for the specific project they’ve been generated for (for the specific metrics that can be returned by a badge). That’s the only access they offer.

Even with the limited amount of information a badge token can share, it can still be revoked and regenerated if needed. Meanwhile, a global setting would mean that if there was a security concern, you’d have to shut down access to all badges.

Thank you very much for letting me know about the badge tokens. I was not previously aware of those and that’s an immediate if imperfect solution. Thank you for taking the time to educate me here.

It’s imperfect for us since our SonarQube instance has 4500+ repos being helped. We automatically create the SonarQube project based on the gitlab project using a common script - the URL of the SonarQube project is pre-defined and closely related to the gitlab repo.

At this scale (4500 repos so far and growing), it’s tedious and error prone to manually create the badges of each of the repos. It’s far easier to create the badges on the gitlab organization level - it’s an order of magnitude easier and something we’d like to automate via script.

If these badges can be auto-created on gitlab orgs without having to hit the SonarQube server, we can easily auto-create these badges consistently across Indeed. That’s the value we’re trying to create.

So, yes, we can manually create badges on every project manually. There’s a much bigger win we’d like to achieve.

Have you considered looking at the APIs in the api/project_badges domain? This might be useful for you to automate. Here’s the documentation on our own instance of SonarQube.

Thank you very much. That’s something we can definitely use for automation. I appreciate you taking the time to give me some options here.

I’m good here then, I’d always like it to be easier of course :slight_smile: and I have paths forward I can take.

Thank you very much for your time and the possible ways forward!
Larry Diamond

1 Like