Calling `api/v1/version` without valid token works

[cincuranet]

I can call api/v1/version without valid token and I get back version. Is that expected? My expectation is that it should fail. Exposing freely the server version is small clue that attacker might find potentially useful.

Same for heartbeat call. But I don't have strong opinion on this (my general expectation would be that every endpoint requires auth, when auth is enabled).

[tazarov]

hey @cincuranet, thanks for raising this.

We have the below. But after recent changes I noticed that support for chroma_server_auth_ignore_paths has been removed (by mistake or intentionally I can tell right now).

chroma/chromadb/config.py

Lines 190 to 197 in b028309

	chroma_server_auth_ignore_paths: Dict[str, List[str]] = {
	f"{APIVersion.V2}": ["GET"],
	f"{APIVersion.V2}/heartbeat": ["GET"],
	f"{APIVersion.V2}/version": ["GET"],
	f"{APIVersion.V1}": ["GET"],
	f"{APIVersion.V1}/heartbeat": ["GET"],
	f"{APIVersion.V1}/version": ["GET"],
	}

Is controlling access to version and HC important for your use case?

[cincuranet]

Is controlling access to version and HC important for your use case?

I found it while working on auth validation tests in https://github.com/ssone95/ChromaDB.Client. So not a big deal in this case - instead of calling version, I can create collection or something similar.

On the other hand, it surprised me, because my mental model was like I described above.

[tazarov]

I understand your point of view. Which is why we had chroma_server_auth_ignore_paths that made sense initially, to allow things to be more configurable (misconfigurable too). I think in most settings HC can be considered an acceptable endpoint to expose for LBs. In hindsight exposing version is indeed a vector of attack.

I think that any serious deployment of Chroma must have reverse proxy or some sort of LB, which is why we did not consider this to be a big security risk to begin with.