You probably should not use ads networks that run javascript from random domains. You'll end up serving malware, infecting your users and getting banned by search engines' safe browsing.
You can still whitelist valid ads network domains.
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.
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.
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".
