Add security headers

[w00000dy]

This pull request adds several security headers to the HTTP responses.

Before	Now
Result	Result
BlueMap	BlueMap

https://bluecolored.de/bluemap/ uses nginx, but the result would be the same on the BlueMap web server.

Security improvements:

This adds several HTTP security headers to all responses, including Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.

I didn't include Strict-Transport-Security because BlueMap's web server doesn't handle HTTPS. If you use a reverse proxy (like Nginx, Caddy, or Cloudflare) for HTTPS, set this header there.

I also changed the Server HTTP header from a versioned string (e.g., BlueMap/1.0) to simply BlueMap.

What does not work anymore:
If users load their own scripts or CSS cross-origin, this is now blocked by CSP. If we should change this just let me know.

[TBlueF]

Hi @w00000dy, thank you for the PR!
However, I don't think we should add this.

Most People that are using the integrated webserver are either not super "techy" or are just hosting bluemap casually for a very small server.
Introducing these headers means that there will be a high potential for additional hurdles and issues people will face when trying to use bluemap in this way, while having no real benefit at all.
If people want to have these headers and benefit from them, then this is usually a less casual usecase and then it is recommended anyways to switch to an external webserver like nginx or apache, where users can setup these headers already by themselves.

-> Keep the integrated webserver casual, with no focus on ssl or "security", use a "proper" external webserver if these advanced options are needed :)

[w00000dy]

Hi @TBlueF,

Thank you for taking a look at my PR!
The only header that could cause problems is the Content-Security-Policy header. If you have any concerns, we can make this setting less restrictive.
As you can see in my current deployment, it already works without any problems: https://mc.woody.pizza/. 😁
We should not view the integrated web server as one that doesn't focus on security because we must expect that users will expose it to the internet. Secure defaults protect non-technical users who wouldn't otherwise add these headers.
We should be secure by default, not insecure by default. Having these headers already defined in the BlueMap web server also has the advantage that we don't need to explicitly set them in our reverse proxy because they will usually be passed through.
Also, advanced users are unaffected. People who use a reverse proxy can still overwrite the header through the proxy if they need to.

Therefore, my suggestion would be to make the Content-Security-Policy less restrictive to minimize the risk of breaking something.

[TBlueF]

@w00000dy I ofc agree with the "secure by default" approach, but...

There is already users who just embed their bluemap hosted by some gameserver-host in their static website and are happy with not having any https on both. X-Frame-Options will break that.

There also might be users that use custom scripts that might break with the Permissions-Policy header.

So Strict-Transport-Security, Content-Security-Policy, X-Frame-Options and Permissions-Policy are headers I would like to avoid, especially without a way to turn them off in the config.

You also removed the version from the Server header, which i would like to keep. (Any reason you removed that?)

My suggestion would be:

Add a config in the webserver.conf looking like this:

additional-headers: {
  #"Content-Security-Policy": "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; object-src 'none';"
  "X-Frame-Options": "SAMEORIGIN"
  "X-Content-Type-Options": "nosniff"
  "Referrer-Policy": "strict-origin-when-cross-origin"
  "Permissions-Policy": "accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(self), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(self), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()"
}

And use that config to send the configured headers with the internal-webserver.

That way we not just hardcode some fixed headers and values, instead we add a new powerful feature with a reasonably secure default configuration and a very straight forward way for the user to turn them off or change them. Or even add new ones! :)

I would be happy to merge a PR that implements this cleanly 👍

[w00000dy]

I like the idea of adding a configuration to the web server configuration file. 👍🏼 I'll try to implement it.

I removed the version from the Server header for defense in depth. Let's assume that BlueMap version 5.2 contains a critical security vulnerability. You can then use this server header to scan the internet for all outdated BlueMap installations.
See: https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server

[TBlueF]

The version in the header and in other places is one of the most important tools for us to help and support people that have issues with their setup. I am looking at that exact header daily while analyzing support-questions in our discord :D
So this needs to stay :)