Feature request: Allow disabling the server header entirely

[PokkaKiyo]

Greetings!

I would like to request the ability to disable the default server header entirely, as showing the default server: Granian header does raise some best practice issues for my projects.

I've already checked that there is a related PR #522, which would allow me to send a server header with some obscured value in every response, but I would like the ability to optionally not have the header be inserted at all.

For reference against other third party libraries, in uvicorn, this can be achieved with the command line option --no-server-header or environment variable "UVICORN_SERVER_HEADER"=0 (https://www.uvicorn.org/settings/#http)

[aldem]

Disabling server header would help in cases when the response is generated by Granian itself (some 400 responses).

This is really a bit uneasy as it is enough to generate a bad request to find out which server is behind the endpoint, as this request wouldn't even reach the app (and won't be logged, usually).

Probably even better - would be nice to be able to define which header should be sent if none is explicitly present in headers - it may be set to empty value to completely disable it.

[aldem]

Any chance to implement this or we are forced to run Granian behind a reverse proxy to remove/replace default Server header? :)

The problem with the current implementation is (as I mentioned above) - if an app fails to send any headers or when Granian answers on its own, the default header is always sent.

[gi0baro]

tbh, I don't see any actual security exposure here. Thus, given the code changes needed are definitely not trivial, at this stage this is a very low priority to me.

[aldem]

As long as Granian has no (known) security issues (or anything that could be exploited) - this is not a problem.

However, if something is found/introduced in the future - then potential attackers will already have a list of servers that are known to run Granian, thus attack could be targeted.

But what makes this not trivial, by the way? As far as I see this is just headers.entry(HK_SERVER).or_insert(HV_SERVER); - adding an if around few places where it is used or using a variable in place of HV_SERVER seems trivial to me... or do I miss something?

[gi0baro]

As long as Granian has no (known) security issues (or anything that could be exploited) - this is not a problem.

However, if something is found/introduced in the future - then potential attackers will already have a list of servers that are known to run Granian, thus attack could be targeted.

Even in that case, it's not a concern to me. No version is exposed, so it's like knowing a service run on cloudflare (Nginx and or pingora) or Google cloud (envoy). It's not really an attack vector to me tbh.

But what makes this not trivial, by the way? As far as I see this is just headers.entry(HK_SERVER).or_insert(HV_SERVER); - adding an if around few places where it is used or using a variable in place of HV_SERVER seems trivial to me... or do I miss something?

That variable comes from Python. So in addition to cloning/arc, it needs to also be passed to contexts in which we don't have the interpreter. So yeah, to me it's not trivial. But I'm open to PRs. As I said, it's not a priority for me.

[apawlucz-cisco]

Just wanted to voice an opinion it would be nice to have the ability to disable Server header completely.

By comparison - e.g. hypercorn allows that by setting include_server_header flag to False for the embedded server.

To quote OWASP recommendations:

• https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html#server

Remove this header or set non-informative values.

Good thing is I'm able to set this header to un-informative value using Starlette middleware. Would be even better to have the ability to unset this header completely.

Thank you!

[aldem]

@apawlucz-cisco ASGI framework middleware won't help if a request fails before it is reached, or even if there is an (unhandled or improperly handled) exception and no response is sent at all.

This is actually my original concern... the only reliable workaround for now is to have something in front (reverse proxy) that takes care about the Server header.

[apawlucz-cisco]

@aldem

ASGI framework middleware won't help if a request fails before it is reached, or even if there is an (unhandled or improperly handled) exception and no response is sent at all.

Indeed this sounds like a valid concern, I did not think about this scenario.

On the other hand having a reverse proxy in front only for this purpose is an overkill, and in our case definitely not viable.

So this makes having a feature to disable the Server header completely even more valid.

[aldem]

And few more cents to the issue... It turns out that disclosing server banner (even only name) is enough to not pass PCI-DSS compliance scan... Just got my new report - now it is flagged as having "Medium" severity and could not be flagged as "false positive". The explanation (section "impact") is:

Many times server banner includes a version number of the server or the technology used. Information of known security issues for particular versions of servers are available on various security forums. Even if such version number is not present, knowing the server or technology may help the attacker to perform more focused attacks.

And they are right...