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 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.
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.
So, it’s still unclear to me how one should use badges with, e.g., the README file in a repository.
Exposing tokens in a repository, even a unique one, trips up every security alarm in our system. This is just not a very good solution. In addition, manually creating these links in X many repositories is simply never going to happen.
The API call still requires someone with a token to process it., and putting that into CI/CD (with the attendant commits that would be required) is not a viable solution either IMO.
At the moment, badges seem like a pretty useless feature to me after the token requirement was added. And the result is that Sonarqube becomes less useful to us, because issues are surfaced to the org in a slower manner.
I’m not really sure what to suggest: the options are either unauthenticated access you can’t revoke, or authenticated access with a very narrow scope that you can revoke if needed.
Larry does suggest the solution - providing fine(r)-grained permissions. Such as allowing unauthenticated access to just the badges without requiring that one also switch of security for everything else. Any solution that one would build to work around this would essentially be doing exactly that anyway.
I don’t particularly care that an anonymous person can see that Sonar evaluates a project to a B on some metric. I do care if an anonymous person is able to access Sonar and see the exact lines of code that are causing a security issue and details of the specific vulnerability involved. Having those permissions being treated as being equally dangerous makes zero sense, IMO.
Fine-grained permissions are the solution to this kind of issue; it allows the user to determine what kind of risk they are willing to accept for themselves.
and I have paths forward I can take.