3 ms·

Content-Security-Policy would break ads. That's the main reason why so few sites use it. X-Frame-Options is fine, since modern ads use JS and not IFRAMEs. X-C

Content-Security-Policy would break ads. That's the main reason why so few sites use it. X-Frame-Options is fine, since modern ads use JS and not IFRAMEs. X-Content-Type-Options is fine because you are essentially telling the browser to trust the mime-type and not speculatively parse the resource. You know what the mime-types should be so no problem here Strict-Transport-Security is fine as well. It also has the added benefit of forcing SSL for all traffic, and thus could be used to force SPDY instead of HTTP for 50%+ of a website's visitors, which is a huge performance win.

duskwuff 13y ago
> X-Frame-Options is fine, since modern ads use JS and not IFRAMEs. Also because X-Frame-Options restricts what can frame you, not what you can load in frames.
yeukhon 13y ago
The only downside of Strict-Transport-Security is that you must have at least visited the HTTPS endpoint once. Therefore, the sane way is to do 301 redirect from all HTTP to HTTPS and HTTPS response header must include Strict-Transport-Security.
- mischa_u 13y ago
  Should the HTTP response also include the Strict-Transport-Security header?
  - yeukhon 13y ago
    No. The header is enforced on https connectiin only.
  - revasm 13y ago
    No: Note: The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header. https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric... Also read RFC 6797, section 7.2 in particular. An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. and If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301 (Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https". https://tools.ietf.org/html/rfc6797 https://tools.ietf.org/html/rfc6797

duskwuff 13y ago

> X-Frame-Options is fine, since modern ads use JS and not IFRAMEs. Also because X-Frame-Options restricts what can frame you, not what you can load in frames.

yeukhon 13y ago

The only downside of Strict-Transport-Security is that you must have at least visited the HTTPS endpoint once. Therefore, the sane way is to do 301 redirect from all HTTP to HTTPS and HTTPS response header must include Strict-Transport-Security.

mischa_u 13y ago
Should the HTTP response also include the Strict-Transport-Security header?
- yeukhon 13y ago
  No. The header is enforced on https connectiin only.
- revasm 13y ago
  No: Note: The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header. https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric... Also read RFC 6797, section 7.2 in particular. An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. and If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a status code indicating a permanent redirect, such as status code 301 (Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https". https://tools.ietf.org/html/rfc6797 https://tools.ietf.org/html/rfc6797