Bug 53685

Created attachment 81064 [details] Patch

Adam, not sure this is the right place to add the policy?

Comment on attachment 81064 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=81064&action=review > Source/WebCore/page/ContentSecurityPolicy.cpp:38 > -ContentSecurityPolicy::ContentSecurityPolicy() > +ContentSecurityPolicy::ContentSecurityPolicy(Frame* frame) > + : m_frame(frame) > +{ > +} The policy should be on the Document because the policy is scoped to a given document. The Frame survives navigation between documents, but the policy doesn't. > Source/WebCore/page/ContentSecurityPolicy.cpp:49 > +bool ContentSecurityPolicy::isEnabled() const > { > + DEFINE_STATIC_LOCAL(String, CSPHeader, ("X-WebKit-CSP")); > + > + Frame* frame = m_frame; > + if (frame->document()->url() == blankURL()) > + frame = m_frame->tree()->parent(); > + > + return !frame->loader()->documentLoader()->response().httpHeaderField(CSPHeader).isEmpty(); > } It looks like you copied this logic from XSSAuditor, but that logic was somewhat specific to that case (especially the blankURL bit). This design won't scale well when we have to do more complex parsing of the policy header. Instead, we should have WebCore call into this object when the header is available, so that it can parse the header once and remember what it said. You can look at how this works for X-Frame-Options.

Attachment 81064 [details] did not build on mac: Build output: http://queues.webkit.org/results/7693384

@jochen: We should also mark these bugs as blocking the meta bug so folks can follow our progress via the meta bug.

Created attachment 81279 [details] Patch

Comment on attachment 81279 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=81279&action=review Mostly organizational comments. We want to put as much of the "guts" inside ContentSecurityPolicy as possible. The outside code should be as oblivious as possible. > Source/WebCore/dom/Document.cpp:4622 > +void Document::parseContentSecurityPolicyHeader(const String& header) > +{ > + // FIXME: Actually parse the header. > + m_contentSecurityPolicy.setEnabled(!header.isEmpty()); > +} parse should be a method on ContentSecurityPolicy. It's the one that's going to do the heavy lifting. > Source/WebCore/dom/Document.h:1093 > + void parseContentSecurityPolicyHeader(const String&); We should just have an accessor for m_contentSecurityPolicy > Source/WebCore/loader/MainResourceLoader.cpp:362 > + m_frame->loader()->didReceiveContentSecurityPolicyHeader(content); I'd just change this to call through to the document->contentSecurityPolicy()->didReceiveHeader(content), which can then call parse internally.

Attachment 81279 [details] did not build on mac: Build output: http://queues.webkit.org/results/7704048

Created attachment 81349 [details] Patch

Comment on attachment 81349 [details] Patch Thanks!

Created attachment 81350 [details] Patch

Fixing the header attributes so it compiles on mac.

Comment on attachment 81350 [details] Patch Clearing flags on attachment: 81350 Committed r77742: <http://trac.webkit.org/changeset/77742>

Attachment 81349 [details] did not build on mac: Build output: http://queues.webkit.org/results/7702330

The commit-queue encountered the following flaky tests while processing attachment 81350 [details]: http/tests/websocket/tests/handshake-error.html bug 53851 (author: abarth@webkit.org) The commit-queue is continuing to process your patch.