Nginx中的HSTS:是否应该在子域服务器块中添加Strict-Transport-Security标头?

前端之家收集整理的这篇文章主要介绍了Nginx中的HSTS:是否应该在子域服务器块中添加Strict-Transport-Security标头?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

让我们将以下Nginx.conf配置文件与example.com和subdomain.example.com的服务器块一起使用:

http {
    ...

    server {
        listen [::]:80 ipv6only=off default_server;
        server_name example.com;
        return 301 https://example.com$request_uri;
    }
    server {
        listen [::]:443 ipv6only=off ssl default_server;
        server_name example.com;
        add_header Strict-Transport-Security
            "max-age=63072000; includeSubDomains; preload" always;
        ...
    }

    server {
        listen [::]:80 ipv6only=off;
        server_name subdomain.example.com;
        return 301 https://subdomain.example.com$request_uri;
    }
    server {
        listen [::]:443 ipv6only=off ssl;
        server_name subdomain.example.com;
        add_header Strict-Transport-Security
            "max-age=63072000; includeSubDomains; preload" always; # <-- again ???
        ...
    }
}

标题的includeSubDomains部分显然告诉浏览器标题也适用于所有子域.

但是,如果该浏览器在看到example.com之前访问了subdomain.example.com,那将不会有任何帮助,是吗?因此,为了涵盖这种情况,我需要在所有子域服务器块中添加相同的add_header …对吗?

最佳答案
你是正确的,最好是有严格HSTS,交通运输安全头无处不在,你需要它,以确保客户得到它,即使sub.example.com之前example.com访问或如果缓存的HSTS信息已过期.

includeSubDomains标志会影响它所在的​​所有子域.这意味着sub.example.com上的includeSubDomains对* .sub.example.com而不是* .example.com生效. (这很自然,因为如果例如example.co.uk可能影响* .co.uk会很糟糕.)

>如果您不使用任何sub.sub.example.com,则可以保留子域的Strict-Transport-Security标头,而不使用此标志.
> subA.example.com无法保护s​​ubB.example.com.

猜你在找的Nginx相关文章