Implement Security Headers by Default

matbrgz

Security headers are HTTP response headers that characterize whether a set of security safeguards ought to be activated or deactivated on the internet browser.

The .htaccess could be configured by default with those options:

<IfModule mod_headers.c>
# Fix for https://httpoxy.org vulnerability
  RequestHeader unset Proxy

# X-XSS-Protection
  Header set X-XSS-Protection "1; mode=block"

# Permissions-Policy
  Header always set Permissions-Policy "geolocation=(); midi=();notifications=();push=();sync-xhr=();accelerometer=(); gyroscope=(); magnetometer=(); payment=(); camera=(); microphone=();usb=(); xr=();speaker=(self);vibrate=();fullscreen=(self);"

# Strict-Transport-Security
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
</IfModule>

Best Regards

luceos

Thanks for these suggestions 👍️

From what I can read X-XSS-Protection is only for legacy browsers and as such not something we actively support.

matbrgz RequestHeader unset Proxy

This might make sense, not from a core standpoint but for environments with many extensions.

matbrgz Permissions-Policy

Actively blocking browser features would potentially cause confusion for users adding extensions that utilize any of these features. I haven't read all of the given features, but pro-actively blocking iframes, geolocation and push would probably break extensions. This could definitely be part of a "Harden your Flarum installation" series though.

matbrgz Strict-Transport-Security

I like this one. But this would only make sense for communities with active SSL certificates. Or am I missing something, @clarkwinkelmann seems to have included it in his lab too.

matbrgz

luceos By Default,m Flarum must use HTTPS since HTTP is flagged to die. So should bring others .htaccess rules like:

<IfModule mod_rewrite.c>
# Force non-www in a Generic Way
  RewriteCond %{HTTP_HOST} ^www\.
  RewriteCond %{HTTPS}s ^on(s)|off
  RewriteCond https%1://%{HTTP_HOST} ^(https?://)(www\.)?(.+)$
  RewriteRule ^ %1%3%{REQUEST_URI} [R=301,L]

# Force HTTPS
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Just for Your Information:

https://securityheaders.com/?q=discuss.flarum.org&hide=on&followRedirects=on

rob006

Using Strict-Transport-Security with includeSubDomains could backfire, since it could affect domains unrelated to forum. In general I don't think that forum engine should set such headers - as long as Flarum will not provide SSL certificates on its own, it should not set headers forcing SSL.

clarkwinkelmann

Yeah the problem with Strict-Transport-Security is that it's not a single on/off header, it contains optional parameters. If we generate that header from Flarum, it requires multiple setting fields.

Building that header from Flarum settings also impacts performance more than just putting it in the Apache/nginx header config.

Like rob says, includeSubDomains could backfire, and so does preload. No software should force the preload option upon a website, it has to be opt-in.

The https://httpoxy.org line is irrelevant for Flarum, it's useful to have in the Apache/nginx configuration, but it's in case outdated CGI scripts are enabled on the hosting. Flarum itself or its extension never contained that vulnerability so there's no reason filtering the header inside of Flarum's stack.

What we could do however is add the suggested headers as comments in the included .htaccess file, similar to how we include the rules for non-public folder https://github.com/flarum/flarum/blob/master/public/.htaccess