Is the X-API-Key header always required now?

rasa · April 20, 2025, 12:39am

On HTTP Utility Services API — Syncthing documentation it says that “These services are available via HTTP on the GUI listen address, but in contrast to the REST API do not require any form of authentication or an API key.”

Hitting http://localhost:8384/meta.js or http://localhost:8384/qr/?text=test with curl, they seem to require --insecure to avoid SSL certificate problem and --header 'X-API-Key: xxx' to avoid 403 Forbidden. Are the docs are out of date, or is my system misconfigured in some way?

foo · April 20, 2025, 8:24am

Could you please briefly describe your environment? What version of syncthing are you on?

What I can add is that on my system running:

curl  --silent --unix-socket /tmp/st* \
    'http://_/qr/?text=Hello%2C%20world%21' | file -

gives:

/dev/stdin: PNG image data, 232 x 232, 1-bit grayscale, non-interlaced

This is with syncthing-1.27.10 from OpenBSD 7.6 ports.

calmh · April 20, 2025, 1:58pm

I believe this may be out of date. Some things changed slightly when the login page was added, iirc.

rasa · April 20, 2025, 3:21pm

I initially saw it on syncthing v1.28.0 (debian build) on Ubuntu 24.10. But 1.29.4 exhibits this behavior too. Should I submit a PR to fix the docs or try to fix the code instead?

foo · April 21, 2025, 2:15pm

Just now I tried to reproduce using on alpine-linux 3.21, using syncthing-1.28.1-r4 which ought to be from between those versions you’ve experienced the issue with. I am still allowed to use the API unauthenticated, with identical results as on the OpenBSD machine.

My vote would be for trying to fix the code, or at least get to the bottom with why it happens on your machine but not one mine.

calmh · April 21, 2025, 2:42pm

The only way I expect those paths to not require authentication if is you’ve not enabled authentication. I have no strong opinion either way, the QR thing is not sensitive but also not something I think we need to provide as a general service without authentication? meta.json similarly is probably not sensitive but no real reason to serve it without auth afaik…

github.com/syncthing/syncthing

lib/api/api_auth.go

c316c3ce0


      
          func isNoAuthPath(path string, metricsWithoutAuth bool) bool {
          	// Local variable instead of module var to prevent accidental mutation
          	noAuthPaths := []string{
          		"/",
          		"/index.html",
          		"/modal.html",
          		"/rest/svc/lang", // Required to load language settings on login page
          	}
          
          	if metricsWithoutAuth {
          		noAuthPaths = append(noAuthPaths, "/metrics")
          	}
          
          	// Local variable instead of module var to prevent accidental mutation
          	noAuthPrefixes := []string{
          		// Static assets
          		"/assets/",
          		"/syncthing/",
          		"/vendor/",
          		"/theme-assets/", // This leaks information from config, but probably not sensitive

This file has been truncated. show original

foo · April 22, 2025, 2:39pm

Correct. No username or password enabled here. My sockets are always created in directories only the launching user has permissions to. Everyone able to connect can also read the configuration file.

If I read the code correctly, the documentation would for sure benefit from being updated. Any instance configured to require username and password authentication may be accessed without those, as an api key short-circuits that elevated security? That’s unexpected.