New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Fixed
Closed: Feb 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 811691: CSP object-src 'none' allows load of image in <object> tag

Reported by, Feb 13 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce the problem:
header("Content-Security-Policy: object-src 'none'");
<object data=""></object>

What is the expected behavior?

What went wrong?
When CSP set `object-src 'none'`, Chrome let the image in object tag show while Firefox block it

Did this work before? N/A 

Chrome version: 64.0.3282.140  Channel: stable
OS Version: OS X 10.13.3
Flash Version: Shockwave Flash 28.0 r0

Comment 1 by, Feb 13 2018

Components: Blink>SecurityFeature>ContentSecurityPolicy
Labels: Security_Impact-Stable

Comment 2 by, Feb 13 2018

Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Summary: CSP object-src 'none' allows load of image in <object> tag (was: CSP objec-src 'none' let image in <object> tag load)
Image is blocked as expected in Firefox and Edge.

Image is not blocked in Chrome 63 to 66 ToT and Safari Stable/TP.

Comment 3 by, Feb 13 2018

The image request enters ContentSecurityPolicy::AllowRequest with a context of 
WebURLRequest::kRequestContextImage, so the object-src policy isn't evaluated. This appears to be a violation of CSP2 and CSP3, which note: 

"Note: The object-src directive acts upon any request made on behalf of an object, embed, or applet element. This includes requests which would populate the nested browsing context generated by the former two (also including navigations). This is true even when the data is semantically equivalent to content which would otherwise be restricted by another directive, such as an object element with a text/html MIME type."

Comment 4 by, Feb 13 2018

Our handling of the OBJECT element has a special case for images, whereby it creates a HTMLImageLoader when it sees that the URL has an image-like file extension.

Comment 5 by, Feb 13 2018

Would this be reasonable? It seems to fix the issue, but perhaps there's some other dire outcome of changing the context like this:

--- a/third_party/WebKit/Source/core/loader/ImageLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/ImageLoader.cpp
@@ -391,6 +391,10 @@ void ImageLoader::DoUpdateFromElement(BypassMainWorldBehavior bypass_behavior,
           referrer_policy, url, document.OutgoingReferrer()));

+    if (IsHTMLObjectElement(GetElement()))
+      resource_request.SetRequestContext(
+          WebURLRequest::kRequestContextObject);

Comment 6 by, Feb 13 2018

Labels: Security_Severity-Low

Comment 7 by, Feb 14 2018

you can also load svg file like this : `<object data="1.svg" type="image/jpeg"></object>`
so i think it would be medium severity

Comment 8 by, Feb 14 2018

Re #7, when you load the SVG that way, does it execute script, or is it equivalent to doing <img src="something.svg" />

Comment 9 by, Feb 14 2018

seems like just equivalent to <img src='xxx.svg'

Comment 11 by, Feb 20 2018

Status: Assigned (was: Untriaged)

Comment 12 by, Feb 20 2018

Project Member
The following revision refers to this bug:

commit e56aee6473486fdfac0429747284fda7cdd3aae5
Author: Eric Lawrence <>
Date: Tue Feb 20 19:21:03 2018

Use correct Request Context when EMBED or OBJECT requests an image

When an OBJECT or EMBED element requests an image, it does so using
an ImageLoader. To ensure that Content-Security-Policy restrictions
are applied correctly in this scenario, we must adjust the request's
context to indicate the originating element.

Bug:  811691 
Change-Id: I0fd8010970a12e68e845a54310695acc0b3f7625
Commit-Queue: Eric Lawrence <>
Reviewed-by: Mike West <>
Cr-Commit-Position: refs/heads/master@{#537846}

Comment 13 by, Feb 21 2018

Status: Fixed (was: Assigned)

Comment 14 by, Feb 22 2018

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 15 by, Feb 26 2018

Labels: reward-topanel

Comment 16 by, Mar 4 2018

Will this bug displayed in M65 release notes?

Comment 17 by, Mar 5 2018

Labels: M-66
The fix for this issue will ship in M66.

Comment 18 by, Mar 6 2018

I'm afraid the VRP panel declined to reward for this bug, sorry :-(  Many thanks for the report though!

Comment 19 by, Mar 6 2018

Labels: -reward-topanel reward-0

Comment 20 by, Apr 17 2018

Labels: Release-0-M66

Comment 21 by, Apr 25 2018

Labels: CVE-2018-6114

Comment 22 by, Apr 25 2018

Labels: CVE_description-missing

Comment 23 by, May 31 2018

Project Member
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 24 by, Jan 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment