mirror of
https://github.com/deuill/coreos-home-server.git
synced 2024-09-21 13:40:45 +00:00
193 lines
8.3 KiB
Plaintext
193 lines
8.3 KiB
Plaintext
# Basic site-specific configuration.
|
||
# https://github.com/h5bp/server-configs-nginx
|
||
|
||
# Set a strict Referrer Policy to mitigate information leakage.
|
||
#
|
||
# 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;
|
||
|
||
# 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;
|
||
}
|
||
|
||
# Mitigate the risk of cross-site scripting and other content-injection
|
||
# attacks.
|
||
#
|
||
# This can be done by setting a Content Security Policy which permits
|
||
# trusted sources of content for your website.
|
||
#
|
||
# There is no policy that fits all websites, you will have to modify the
|
||
# `Content-Security-Policy` directives in the example depending on your needs.
|
||
#
|
||
# To make your CSP implementation easier, you can use an online CSP header
|
||
# generator such as:
|
||
# https://report-uri.com/home/generate/
|
||
#
|
||
# It is encouraged that you validate your CSP header using a CSP validator
|
||
# such as: https://csp-evaluator.withgoogle.com
|
||
#
|
||
# https://www.w3.org/TR/CSP/
|
||
# https://owasp.org/www-project-secure-headers/#content-security-policy
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
||
# https://developers.google.com/web/fundamentals/security/csp
|
||
# https://content-security-policy.com/
|
||
|
||
add_header Content-Security-Policy $content_security_policy always;
|
||
|
||
# Set a strict Permissions Policy to mitigate access to browser features.
|
||
#
|
||
# The header uses a structured syntax, and allows sites to more tightly
|
||
# restrict which origins can be granted access to features.
|
||
# The list of available features:
|
||
# https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md
|
||
#
|
||
# The example policy below aims to disable all features expect synchronous
|
||
# `XMLHttpRequest` requests on the same origin.
|
||
#
|
||
# To check your Permissions Policy, you can use an online service, such as:
|
||
# https://securityheaders.com/
|
||
# https://observatory.mozilla.org/
|
||
#
|
||
# https://www.w3.org/TR/permissions-policy-1/
|
||
# https://owasp.org/www-project-secure-headers/#permissions-policy
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy
|
||
# https://scotthelme.co.uk/a-new-security-header-feature-policy/
|
||
|
||
add_header Permissions-Policy $permissions_policy always;
|
||
|
||
# Set strict a Cross Origin Policy to mitigate information leakage.
|
||
#
|
||
# (1) Cross-Origin-Embedder-Policy prevents a document from loading any
|
||
# cross-origin resources that don’t explicitly grant the document
|
||
# permission.
|
||
# https://html.spec.whatwg.org/multipage/origin.html#coep
|
||
# https://owasp.org/www-project-secure-headers/#cross-origin-embedder-policy
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy
|
||
#
|
||
# (2) Cross-Origin-Opener-Policy allows you to ensure a top-level document does
|
||
# not share a browsing context group with cross-origin documents.
|
||
# https://html.spec.whatwg.org/multipage/origin.html#cross-origin-opener-policies
|
||
# https://owasp.org/www-project-secure-headers/#cross-origin-opener-policy
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy
|
||
#
|
||
# (3) Cross-Origin-Resource-Policy allows to define a policy that lets web
|
||
# sites and applications opt in to protection against certain requests from
|
||
# other origins, to mitigate speculative side-channel attacks.
|
||
# https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header
|
||
# https://owasp.org/www-project-secure-headers/#cross-origin-resource-policy
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy
|
||
# https://resourcepolicy.fyi/
|
||
#
|
||
# To check your Cross Origin Policy, you can use an online service, such as:
|
||
# https://securityheaders.com/
|
||
# https://observatory.mozilla.org/
|
||
#
|
||
# https://web.dev/coop-coep/
|
||
# https://web.dev/why-coop-coep/
|
||
# https://web.dev/cross-origin-isolation-guide/
|
||
# https://scotthelme.co.uk/coop-and-coep/
|
||
|
||
add_header Cross-Origin-Embedder-Policy $coep_policy always;
|
||
add_header Cross-Origin-Opener-Policy $coop_policy always;
|
||
add_header Cross-Origin-Resource-Policy $corp_policy always;
|
||
|
||
# Serve resources with appropriate cache control directives.
|
||
#
|
||
# The `Cache-Control` header field holds directives (instructions) that control
|
||
# caching in browsers and shared caches (e.g. Proxies, CDNs).
|
||
# Its use targets web performances improvement by specifying the expected
|
||
# client and network caches behaviors.
|
||
#
|
||
# The usable cache directives are listed here:
|
||
# https://www.iana.org/assignments/http-cache-directives/http-cache-directives.xml
|
||
#
|
||
# The cache directives are documented here:
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#response_directives
|
||
#
|
||
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
|
||
# https://www.rfc-editor.org/rfc/rfc9111.html
|
||
# https://www.rfc-editor.org/rfc/rfc8246.html
|
||
# https://www.rfc-editor.org/rfc/rfc5861.html
|
||
# https://www.iana.org/assignments/http-cache-directives/http-cache-directives.xml
|
||
# https://cache-tests.fyi/
|
||
|
||
add_header Cache-Control $cache_control;
|