Omit Server Header from Server Responses by Default

[andrewloux]

Overview

This PR addresses an unnecessary and potentially harmful default setting in the Warp server that automatically includes the Server header in all responses, explicitly revealing the server version as Warp/3.3.23.

Problem

The presence of the Server header could inadvertently aid attackers by exposing specific software versions, which could be exploited if known security holes are present. The potential risks are outlined in RFC 2068 and further discussed in this article by Troy Hunt. The offending default can be located in the Warp server's source code here.

Solution

This PR proposes to disable the Server header by default, significantly reducing the exposure of potentially sensitive information.

I can also revise this to make it configurable if need be; but I think this is a sane default.

Impact

Removing the Server header will mainly impact transparency, and should not disrupt functionality. There's a slight chance that clients relying on the header for metrics or logging might be affected. But given that the Server header offers no functional benefit to client-server interactions, these cases should be rare.

Changelog

Component : server

Type: bugfix

Product: community-edition

Short Changelog

Server header in server responses are omitted.

Long Changelog

The Server HTTP header is no longer included in server responses by default. This change enhances security by withholding potentially sensitive information about the server version that could aid attackers in identifying known security vulnerabilities. This new default behavior aligns with the recommendations in RFC 2068.

Related Issues

• Warp: don't send the Server header by default yesodweb/wai#619

Steps to test and verify

Hitting the healthcheck endpoint is the easiest way here :)

Catalog upgrade

Does this PR change Hasura Catalog version?

• No
• Yes
  • Updated docs with SQL for downgrading the catalog

Metadata

Does this PR add a new Metadata feature?

• No
• Yes
  • Does run_sql auto manages the new metadata through schema diffing?
    • Yes
    • Not required
  • Does run_sql auto manages the definitions of metadata on renaming?
    • Yes
    • Not required
  • Does export_metadata/replace_metadata supports the new metadata added?
    • Yes
    • Not required

GraphQL

• No new GraphQL schema is generated
• New GraphQL schema is being generated:
  • New types and typenames are correlated

Breaking changes

• No Breaking changes

• There are breaking changes:

  1. Metadata API

     Existing query types:

     • Modify args payload which is not backward compatible
     • Behavioural change of the API
     • Change in response JSON schema
     • Change in error code

  2. GraphQL API

     Schema Generation:

     • Change in any NamedType
     • Change in table field names

     Schema Resolve:-

     • Change in treatment of null value for any input fields

  3. Logging

     • Log JSON schema has changed
     • Log type names have changed

On the off-change that clients rely on the header for metrics or logging - they may experience a degradation. This is a highly unlikely scenario though.

[hasura-bot]

Beep boop! 🤖

Hey @andrewlouis93, thanks for your PR!

One of my human friends will review this PR and get back to you as soon as possible.

Stay awesome! 😎

[hasura-bot]

Beep boop! 🤖

Awesome work @andrewlouisx!

Your changes were merged successfully. All of us at Hasura ❤️ what you did.

Thanks again 🤗

[jflambert]

@andrewlouisx this actually broke my integration

can also revise this to make it configurable if need be

this should have been part of the PR. For now I'll downgrade to Hasura v2.34