403 Unauthorized on '/api/server/version' for VSTS pipeline analysis

Azure DevOps (VSTS) build pipeline is failing to communicate with SonarQube. This started occurring without making any changes on our end Q4 last year.


  • Both build agent and SonarQube server are on-prem. No firewall or proxy between.
  • SonarQube IIS app config has only anonymous enabled and no authorization limitations.
  • SonarQube configured to run as a Windows service.
  • No IIS logs indicating denial can be found.
  • Issue occurred with SonarQube 6.7.1 and 7.5.
  • VSTS build step is “Prepare Analysis Configuration” version 4.5.1.
  • Version URL is accessible by me directly with no issue.

Error received is:

2019-01-17T20:38:09.1064192Z ##[section]Starting: Prepare analysis on SonarQube
2019-01-17T20:38:09.1068110Z ==============================================================================
2019-01-17T20:38:09.1068190Z Task         : Prepare Analysis Configuration
2019-01-17T20:38:09.1068260Z Description  : Prepare SonarQube analysis configuration
2019-01-17T20:38:09.1068315Z Version      : 4.5.1
2019-01-17T20:38:09.1068379Z Author       : sonarsource
2019-01-17T20:38:09.1068440Z Help         : [More Information](http://redirect.sonarsource.com/doc/install-configure-scanner-tfs-ts.html)
2019-01-17T20:38:09.1068533Z ==============================================================================
2019-01-17T20:38:09.9368581Z ##[error][SQ] API GET '/api/server/version' failed, status code was: 403
2019-01-17T20:38:09.9453548Z ##[section]Finishing: Prepare analysis on SonarQube

Error occurs every build, so all SonarQube analysis is failing. For now we’re just ignoring errors in these build steps.

Any help or ideas would be very helpful. Thanks! :slight_smile:


IIRC this is one of the first things that happens in analysis & it’s a very basic call. Did permissions on your SonarQube server change? If you’re analyzing with a token, are you sure it hasn’t been revoked?


Turns out the VSTS build process was trying to route through the proxy for this call, instead of calling the internal service directly. I had to add the internal SonarQube URL to the NO_PROXY environment variable, which then short-circuited the proxy detection logic.

Back up and working now!

1 Like

I have it Microft build agent, but on prem Sonar. And I am getting it too.
What kind of access is needed?

I started to get this error after automatic upgrade from SonarQube extension 4.10 to 4.11 on June 25, 2020 in our Azure DevOps Services organization.

The error is: ##[error][SQ] API GET '/api/server/version' failed, status code was: 403

I use SonarQube on premises. My SonarQube instance is publicly accessible now, version

I noticed that SonarQube API returns 403 error when I do not set User-Agent header.
If I set User-Agent header, API return

PS: Is something changed in this part between versions 4.11 and 4.10? It’s very disappointing that an update can break CI and it’s out of control :frowning:

Hi @wilbit

I don’t think that we changed anything on that side, but let’s troubleshoot.

When you are speaking about the User Agent, which kind of call are you making ? With a curl ? Postman ? Fiddler ? Directly against your SQ instance or through a service ?


Yeah, I figured out that it’s not related to the update.
We configured Amazon WAF and some of its managed rules block HTTP requests without User-Agent header.
I am doing tests to find out what exactly rules block requests without User-Agent.

PS: I use Postman to do HTTP requests

PPS: OK, after a quick tests I found that the next 2 rule sets block HTTP requests without User-Agent header:

  1. Anonymous IP list - AWS-AWSManagedRulesAnonymousIpList, 50 rules - This group contains rules that allow you to block requests from services that allow obfuscation of viewer identity. This can include request originating from VPN, proxies, Tor nodes, and hosting providers. This is useful if you want to filter out viewers that may be trying to hide their identity from your application.
  2. Core rule set - AWS-AWSManagedRulesCommonRuleSet,700 rules - Contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including those described in OWASP publications.

I would like to enable these rule sets. Would you be able to add User-Agent header in the next releases of SonarQube extension for Azure DevOps Services, @mickaelcaro ?

1 Like

any updates here?

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.