coreos-home-server/service/nginx/container/config/server.conf

# Basic site-specific configuration.
# https://github.com/h5bp/server-configs-nginx

# Set a strict Referrer Policy to mitigate information leakage.
#
# (1) The `Referrer-Policy` header is included in responses for resources that are able to request
#     (or navigate to) other resources.
#
#     This includes the commonly used resource types: HTML, CSS, XML/SVG, PDF documents, scripts and
#     workers.
#
# To prevent referrer leakage entirely, specify the `no-referrer` value instead. Note that the effect
# could impact analytics metrics negatively.
#
# To check your Referrer Policy, you can use an online service, such as:
#
# https://securityheaders.com/
# https://observatory.mozilla.org/
#
# https://scotthelme.co.uk/a-new-security-header-referrer-policy/
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

add_header Referrer-Policy $referrer_policy always;

# Prevent some browsers from MIME-sniffing the response.
#
# This reduces exposure to drive-by download attacks and cross-origin data leaks, and should be left
# uncommented, especially if the server is serving user-uploaded content or content that could potentially
# be treated as executable by the browser.
#
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
# https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-v-comprehensive-protection/
# https://mimesniff.spec.whatwg.org/

add_header X-Content-Type-Options nosniff always;

# Protect website against clickjacking.
#
# The example below sends the `X-Frame-Options` response header with the value `DENY`, informing
# browsers not to display the content of the web page in any frame.
#
# This might not be the best setting for everyone. You should read about the other two possible
# values the `X-Frame-Options` header field can have: `SAMEORIGIN` and `ALLOW-FROM`.
#
# https://tools.ietf.org/html/rfc7034#section-2.1.
#
# Keep in mind that while you could send the `X-Frame-Options` header for all of your website's
# pages, this has the potential downside that it forbids even non-malicious framing of your content
# (e.g.: when users visit your website using a Google Image Search results page).
#
# Nonetheless, you should ensure that you send the `X-Frame-Options` header for all pages that allow
# a user to make a state-changing operation (e.g: pages that contain one-click purchase links,
# checkout or bank-transfer confirmation pages, pages that make permanent configuration changes,
# etc.).
#
# Sending the `X-Frame-Options` header can also protect your website against
# more than just clickjacking attacks.
#
# https://cure53.de/xfo-clickjacking.pdf.
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
# https://tools.ietf.org/html/rfc7034
# https://blogs.msdn.microsoft.com/ieinternals/2010/03/30/combating-clickjacking-with-x-frame-options/
# https://www.owasp.org/index.php/Clickjacking

add_header X-Frame-Options $x_frame_options always;

# Protect website reflected Cross-Site Scripting (XSS) attacks.
#
# (1) Try to re-enable the cross-site scripting (XSS) filter built into most web browsers.
#
#     The filter is usually enabled by default, but in some cases, it may be disabled by the user.
#     However, in Internet Explorer, for example, it can be re-enabled just by sending the
#     `X-XSS-Protection` header with the value of `1`.
#
# (2) Prevent web browsers from rendering the web page if a potential reflected (a.k.a
#     non-persistent) XSS attack is detected by the filter.
#
#     By default, if the filter is enabled and browsers detect a reflected XSS attack, they will
#     attempt to block the attack by making the smallest possible modifications to the returned web
#     page.
#
#     Unfortunately, in some browsers (e.g.: Internet Explorer), this default behavior may allow the
#     XSS filter to be exploited. Therefore, it's better to inform browsers to prevent the rendering
#     of the page altogether, instead of attempting to modify it.
#
#     https://hackademix.net/2009/11/21/ies-xss-filter-creates-xss-vulnerabilities
#
# (!) Do not rely on the XSS filter to prevent XSS attacks! Ensure that you are taking all possible
#     measures to prevent XSS attacks, the most obvious being: validating and sanitizing your
#     website's inputs.
#
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
# https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/
# https://blogs.msdn.microsoft.com/ieinternals/2011/01/31/controlling-the-xss-filter/
# https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

add_header X-XSS-Protection $x_xss_protection always;

# Block access to all hidden files and directories except for the
# visible content from within the `/.well-known/` hidden directory.
#
# These types of files usually contain user preferences or the preserved state of a utility, and can
# include rather private places like, for example, the `.git` or `.svn` directories.
#
# The `/.well-known/` directory represents the standard (RFC 5785) path prefix for "well-known
# locations" (e.g.: `/.well-known/manifest.json`, `/.well-known/keybase.txt`), and therefore, access
# to its visible content should not be blocked.
#
# https://www.mnot.net/blog/2010/04/07/well-known
# https://tools.ietf.org/html/rfc5785

location ~* /\.(?!well-known\/) {
  deny all;
}

# Block access to files that can expose sensitive information.
#
# By default, block access to backup and source files that may be left by some text editors and can
# pose a security risk when anyone has access to them.
#
# https://feross.org/cmsploit/

location ~* (?:#.*#|\.(?:bak|conf|dist|fla|in[ci]|log|orig|psd|sh|sql|sw[op])|~)$ {
  deny all;
}