Add CSP header for resources with an active policy

Source/core/frame/csp/CSPDirectiveList.cpp

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "config.h"
 #include "core/frame/csp/CSPDirectiveList.h"
 
 #include "core/dom/Document.h"
 #include "core/dom/SecurityContext.h"
 #include "core/frame/LocalFrame.h"
@@ skipping 396 matching lines @@
 {
     return checkHash(operativeDirective(m_styleSrc.get()), hashValue);
 }
 
 const String& CSPDirectiveList::pluginTypesText() const
 {
     ASSERT(hasPluginTypes());
     return m_pluginTypes->text();
 }
 
+bool CSPDirectiveList::shouldSendCSPHeader(Resource::Type type) const
+{
+    switch (type) {
+    case Resource::XSLStyleSheet:
+        ASSERT(RuntimeEnabledFeatures::xsltEnabled());
+        return !!operativeDirective(m_scriptSrc.get());
+    case Resource::Script:
+    case Resource::ImportResource:
+        return !!operativeDirective(m_scriptSrc.get());
+    case Resource::CSSStyleSheet:
+        return !!operativeDirective(m_styleSrc.get());
+    case Resource::SVGDocument:
+    case Resource::Image:
+        return !!operativeDirective(m_imgSrc.get());
+    case Resource::Font:
+        return !!operativeDirective(m_fontSrc.get());
+    case Resource::Media:
+    case Resource::TextTrack:
+        return !!operativeDirective(m_mediaSrc.get());
+    case Resource::Raw:
+        // This request could be for a plugin, a child frame, a worker, or
+        // something else. If there any potentially relevant policies,
+        // send the CSP header; sending it unnecessarily can't hurt.
+        return !!operativeDirective(m_objectSrc.get()) || !!m_pluginTypes.get() || !!operativeDirective(m_childSrc.get()) || !!operativeDirective(m_frameSrc.get()) || !!operativeDirective(m_connectSrc.get()) || !!operativeDirective(m_manifestSrc.get()) || !!m_formAction.get();

[estark, 2015/03/17 18:27:34]

This is sort of the catch-all where we send a CSP header if there is any policy
that might possibly affect the request. This makes me a little nervous because
if a new element <foo> gets added with a corresponding directive foo-src, it
could easily get left out of this list, and so CSP headers would not get sent
for <foo> resources. Thoughts?

[Mike West, 2015/03/20 14:53:54]

This is fine for now. Eventually, I'd like to see the interface to CSP rewritten
on top of WebURLRequest::RequestContext, which is substantially more granular
(want to do that next? :) I landed https://codereview.chromium.org/398313002 a
while back, reverted because of https://crbug.com/396582 which I never spent the
time to track down).

[estark, 2015/03/20 20:27:52]

Sure, I'll take a look!

+    case Resource::MainResource:
+    case Resource::LinkPrefetch:
+    case Resource::LinkSubresource:
+        return false;
+    }
+    ASSERT_NOT_REACHED();
+}
+
 // policy            = directive-list
 // directive-list    = [ directive *( ";" [ directive ] ) ]
 //
 void CSPDirectiveList::parse(const UChar* begin, const UChar* end)
 {
     m_header = String(begin, end - begin);
 
     if (begin == end)
         return;
 
@@ skipping 309 matching lines @@
             enableInsecureRequestsUpgrade(name, value);
         else
             m_policy->reportUnsupportedDirective(name);
     } else {
         m_policy->reportUnsupportedDirective(name);
     }
 }
 
 
 } // namespace blink