@gguillemas do you have any thoughts here?

It is my opinion (as a former security auditor and penetration tester), that security auditors mostly highlight software versions in headers (and other similar information disclosure findings) when they were unable to find anything else of substance to report. Although it is true that most penetration test reports will include mentions to information disclosed by the tested application, it will usually be reported as an informational finding. However, I think your question is relevant and would like to provide a good answer to why these headers are present and in most cases should not be removed so that you can share it with auditors in case that you think it would be helpful.

Version and product headers provide legitimate clients with information about the application that they are communicating with, which they can use to adapt their interfaces or to debug any issues that arise. For example, these headers are used by the Rust SDK to verify compatibility with the SurrealDB backend. For attackers, these headers can definitely be practical, but are not necessary at all to execute an attack. Since an attacker does not care about error handling, they can simply launch their exploit against every SurrealDB HTTP API without any regard for the version header and collect results for those that are successful. This will, in most cases, not require any additional resources than previously checking the version on the header. Identifying that an HTTP endpoint is serving SurrealDB is likewise trivial, even without the header stating so. The cost of removing the headers is paid mostly by legitimate clients while barely inconveniencing attackers.

On the other hand, it is true that these headers may allow generic fingerprinting attempts (e.g. Shodan) to find and index your backend, making it a more likely target for attackers looking to exploit a vulnerability in a specific version SurrealDB without having to scan the internet themselves.

If your specific security requirements (or your auditors) require that the headers are removed, I agree with your suggestion that stripping them with a reverse proxy might be the easier option today. As for the future, we might want to consider adding options to remove or add headers to the SurrealDB HTTP API, as it may provide the flexibility required for this as well as other applications.

@gguillemas I agree with your explanation, although we get a lot of questions when auditors find these issue and want to see them solved.

But you mention that the SDK can use these headers to verify compatibility. Stripping them will cause issues? I don't think a SDK should depend on http headers for this but use a version function/endpoint check once authenticated for example or use a versioned API path for this. ElasticSearch does also provide engine information with the version on a fixed position.

I agree that the version header should not be the only verification implemented by the SDK and that APIs should be versioned when implementing breaking changes that affect its clients. I assume that this header verification is performed mostly to assist developers in debugging why the SDK is failing to communicate with the backend and to understand how to resolve the issue.

However, I am not certain on how this actually works in the SurrealDB SDKs. Maybe @kearfy can help us with this, since he is the one who originally mentioned this SDK behaviour to me. It makes sense that you want to ensure that stripping the headers via reverse proxy will not generate issues in practice.

That's why I opt for a feature so that you can disable/enable it, like you can in most webservices. If a developer needs the headers for debugging that he can enable them or a situation where it all works and you need to disable them.

Fair enough. I will leave this request open to look into the impact of doing this and the effort required.

@johan-smits you can also fork the DB instead of the proxy overhead, btw there is any progress with this discussion maybe internally ? @gguillemas

Hi @idofilus. We do not have any specific short term plans for this. We are focussed on other things so this is not prioritized. We are still keeping the issue open as I think it may be worth doing. Do you have any similar needs where you need to meet compliance but are unable to strip the headers outside of SurrealDB?

@gguillemas This is a minor issue for sure 😊
My personal reason is that for the current specific project I just prefer the backend to be more stealth rather then knowing the DB which is also the only API service the user interact and they will try to search for way to attack in terms of vulnerabilities (since it's open source and kind of new)
I'll personally just fork & build by my own if we will decide it's a critical thing to hide, I definitely agree it isn't anywhere close to being important enough.
But generally I agree with the author can be useful CLI flag, maybe other people will have different reasons