Web security best practices

Best practices for web security

Cloud CDN and Cloud Load Balancing can help you meet web security best practices, whether you're serving content from Compute Engine instances, a Cloud Storage bucket, or an external origin located outside of Google Cloud.

Set security headers

The HTTP specification has a number of headers that control the following:

Client behavior
How content is embedded
How content is served across domains
Whether to always use TLS (HTTPS) when connecting to that domain

These controls are typically represented as HTTP response headers, which you can set for each backend (origin, in CDN terms) as custom response headers for your external Application Load Balancer and Cloud CDN deployment.

If you are using Cloud Storage and serving web content from your bucket, you can use Cloud CDN in front of your storage bucket to set web security headers and cache popular content.

The most useful web security headers are defined in the following table.

Header name Description Example usage

Header name	Description	Example usage
`Strict-Transport-Security` (HSTS)	Ensures that your domains have valid SSL (TLS) certificates before you set this header. Informs clients that they must connect to your domain directly over HTTPS (SSL/TLS), avoiding the need to redirect from HTTP to HTTPS, which is slower and introduces the risk of a person-in-the-middle attack. Setting this header is effectively irreversible. After caching this header, modern browser clients don't attempt non-HTTPS connections, and users can't access any domain that they received this header for, even if SSL is down. This behavior prevents an attacker from downgrading the secure protocol to the unprotected HTTP (known as a downgrade attack). When serving the `Strict-Transport-Security` header, use caution when adding the `includeSubdomains` or `preload` directives. These directives require any subdomain to use HTTPS, including any internal sites on the same domain. For example, `support.example.com` when served from `example.com`.	Require clients to connect directly over HTTPS for all future connections, caching this directive for up to two years: `Strict-Transport-Security: max-age=3104000`
`X-Frame-Options`	Indicate whether a browser can render a page in a <frame>, <iframe>, <embed>, or <object>. This helps to prevent click-jacking attacks, by not letting your content be embedded into other sites.	Deny all iframing of your site: `X-Frame-Options: DENY` Allow only your site to iframe (embed) itself: `X-Frame-Options: SAMEORIGIN`
`Content-Security-Policy`	To evaluate your site's Content Security Policy, you can use Google's CSP Evaluator tool.	Don't allow in-line scripts, and only load scripts over HTTPS: `Content-Security-Policy: default-src https:`

Strict-Transport-Security (HSTS)

Ensures that your domains have valid SSL (TLS) certificates before you set this header.

Informs clients that they must connect to your domain directly over HTTPS (SSL/TLS), avoiding the need to redirect from HTTP to HTTPS, which is slower and introduces the risk of a person-in-the-middle attack.

Setting this header is effectively irreversible. After caching this header, modern browser clients don't attempt non-HTTPS connections, and users can't access any domain that they received this header for, even if SSL is down. This behavior prevents an attacker from downgrading the secure protocol to the unprotected HTTP (known as a downgrade attack).

When serving the Strict-Transport-Security header, use caution when adding the includeSubdomains or preload directives. These directives require any subdomain to use HTTPS, including any internal sites on the same domain. For example, support.example.com when served from example.com.

Require clients to connect directly over HTTPS for all future connections, caching this directive for up to two years:

Strict-Transport-Security: max-age=3104000

X-Frame-Options

Indicate whether a browser can render a page in a <frame>, <iframe>, <embed>, or <object>. This helps to prevent click-jacking attacks, by not letting your content be embedded into other sites.

Deny all iframing of your site: X-Frame-Options: DENY

Allow only your site to iframe (embed) itself: X-Frame-Options: SAMEORIGIN

Content-Security-Policy To evaluate your site's Content Security Policy, you can use Google's CSP Evaluator tool. Don't allow in-line scripts, and only load scripts over HTTPS: Content-Security-Policy: default-src https:

Use caution when introducing new security headers to existing websites, because they can break third-party scripts, embedded content (for example, in iframes), or other aspects of your sites. Before making changes to your production traffic, we recommend creating a second instance of your backend bucket or backend service and testing.

You can read more about web security headers and best practices on web.dev as well on Mozilla's infosec site.

TLS and certificate management

Managed certificates have the following characteristics:

Are provided at no cost
Can be easily deployed to your load balancers
Automatically renew
Are globally distributed to all of Google's edge locations

TLS provides authenticity by validating that data has not been modified in transit. TLS certificates provide confidentiality by making sure that an eavesdropper cannot determine what is being exchanged between users and servers. This is important for user privacy and security.

With SSL certificates, you can benefit from modern transport protocols, such as HTTP/2 and Google's QUIC protocol, both of which require SSL (TLS). These protocols directly improve the performance of web content, media delivery (such as streaming video), and reliability over congested networks.

Google Cloud supports modern TLS protocols (such as TLS 1.3) across Cloud Load Balancing and Cloud CDN services.

You can use SSL policies to raise the minimum version of TLS. We recommend raising the version to TLS v1.2, if you don't need to support older clients, such as embedded devices or older (more than 10 years old) non-browser clients. Globally, TLS v1.0 and TLS v1.1 represent less than 0.5% of connections across Google Cloud. If you need to identify or associate specific clients with outdated versions of TLS, you can use the {tls_version} variable in a request header. You can then log this information.

What's next

To check whether Cloud CDN is serving responses from cache, see Viewing logs.
To learn about which content is cacheable or non-cacheable, see Caching overview.
To see Cloud CDN's points of presence, see Cache locations.