# 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;