-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harden default Kibana security headers #52809
Comments
Pinging @elastic/kibana-security (Team:Security) |
With regard to With regard to |
Seems reasonable, I agree we can omit
@legrego pointed this out to me earlier in another channel, so I have a call scheduled with someone from the appropriate team this week to discuss and make sure this is adequate for our needs. Setting this header would prevent the path and query params from being sent in the
With this change and using
Because of the way Kibana's apps utilize fragments in URLs, this honestly isn't a big improvement from a security perspective. But the lack of a |
Note: need to reach consensus on prefix for header config values -- probably either |
Regarding Seeing as we already don't expose much information in the path, I've changed that to default to |
I would like us to restart this discussion for 8.0. We should enable some sensible defaults and have an option for customers to disable specific headers if needed. I think the defaults @jportner has in the first comment make sense, the only one missing is X-Frame-Options, which I think we should set to "sameorigin" /cc @legrego |
Agree. Since that would be a breaking change, perhaps we should aim to change the defaults for everything else in 7.x, and change the default for |
We should consider replacing or supplementing I do wonder about usability here though. Users can customize their CSP via |
👍 |
@legrego can I use X-Frame-Options in kibana.yml file? |
Kibana currently uses a
Content-Security-Policy
header by default, but no others. Industry best practices dictate that many other security headers should be utilized.In the past we have advised users to set any desired security headers with
server.customResponseHeaders
. However, this has the following negative impacts:X-Frame-Options
) because that would break some Kibana installationsA https://securityheaders.com/ scan of a default Kibana instance, with TLS enabled, produced this report:
click to see report
I propose adding individual configuration options for the following headers:
Strict-Transport-Security
max-age=31536000
X-Content-Type-Options
nosniff
Referrer-Policy
no-referrer-when-downgrade
X-XSS-Protection
*1; mode=block
X-Frame-Options
*Note: the
X-XSS-Protection
header is no longer needed in modern browsers when using a strongContent-Security-Policy
header, but Kibana still supports IE11 so we should implement it.Additional headers that we may consider adding in the future as browser support increases are
Expect-CT
andFeature-Policy
.Larry edit 2020-10-29:
We do not use the Vary:Origin header
The Mozilla docs say:
If the server sends a response with an Access-Control-Allow-Origin value that is an explicit origin (rather than the "*" wildcard), then the response should also include a Vary response header with the value Origin — to indicate to browsers that server responses can differ based on the value of the Origin request header.
Cache time limit
a preflight response is configured to be cached for a prolonged amount of
time. The time a response is allowed to be cached is conveyed using an
Access-Control-Max-Age response header and a value more than 30 minutes is
considered to be prolonged.
The text was updated successfully, but these errors were encountered: