mirror of
https://github.com/deuill/coreos-home-server.git
synced 2024-09-22 06:00:46 +00:00
Alex Palaistras
f877a72e83
This commit contains a fairly large diff for a fairly small change: moving the `config/common` directory to `host/base` to better reflect its intended use, and promoting `config/service` to the root directory. These changes unlock some improvements in `coreos-home-server-update` processes, which will (assuming `/etc/coreos-home-server/base` exists) keep host-wide systemd services in sync in addition to service-specific ones. Changes have been make to the `Makefile` and a few other places where `config/common` was referenced, but most of this work is renames that are not intended to break compatibility with new or running servers.
126 lines
5.6 KiB
Plaintext
126 lines
5.6 KiB
Plaintext
# 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;
|
|
}
|