Closed Bug 1661075 Opened 3 years ago Closed 3 years ago

crossorigin attribute is not honored for [rel=icon] links


(Core :: DOM: Core & HTML, defect)




83 Branch
Tracking Status
firefox83 --- fixed


(Reporter: jugglinmike, Assigned: andreu)



(Keywords: dev-doc-complete)


(2 files, 2 obsolete files)

OS: GNU/Linux Ubuntu 18.04
Browser: Firefox Nightly 81.0a1 (2020-08-21)

Steps to reproduce the problem:

  1. Open the attached document in the browser (contents included here for clarity):

    <!DOCTYPE html>
    <html lang="en">
    <meta charset="utf-8">
    <link rel="icon" href="" crossorigin>

Expected result: the browser does not associate the referenced image with the current document (because the image is not served with the appropriate CORS headers)

Actual result: the browser associates the referenced image with the current document

The attached document sets the crossorigin attribute to "anonymous", but the bug is also present for the empty value ("") and for "use-credentials".

According to the "default fetch and process the linked resource" algorithm:

  1. Let corsAttributeState be the current state of the el's crossorigin content attribute.

Which is used in "create a potential-CORS request":

  1. Let mode be "no-cors" if corsAttributeState is No CORS, and "cors" otherwise.

Fetch's "main fetch":


  1. Set request’s response tainting to "cors".
  2. Return the result of performing an HTTP fetch using request.

And "HTTP fetch":

  1. If request’s response tainting is "cors" and a CORS check for request and
    response returns failure, then return a network error.

This behavior suggests that the request's mode is being set to "no-cors" regardless of the value of the crossorigin attribute. Likewise, the request header Sec-Fetch-Mode is set to "no-cors" in all cases.

The unexpected behavior is also exhibited by Chromium:

Hey Anne! Given that Firefox and Chromium currently agree on this, I may have misinterpreted something. Even in that case, though, a spec change may be in order, since it seems like this request's "destination" ought to be "image", and we'd need a custom "fetch and process the linked resource" algorithm for that. I'm happy to follow up with spec patches as necessary.

Flags: needinfo?(annevk)

I think that this is something that we'd ideally support CORS for to (in theory) allow the image to be used in several places with the same backing cache. I agree with you that the destination ought to be "image". If you can fix that standards-wise that'd be great.

Blocks: 1551557
Flags: needinfo?(annevk)

There's already a hook for this sort of thing, so the spec patch is surprisingly small:

Assignee: nobody → abb
Attachment #9181540 - Attachment is obsolete: true
Attachment #9181547 - Attachment is obsolete: true
Pushed by
Switch the security checks when loading favicons depending on the crossorigin attribute. r=mossop
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Suggested text for MDN: "The crossorigin attribute is now supported for <link rel=icon>."

Keywords: dev-doc-needed

Looks like the docs have been completed for this one; see for the full details.

You need to log in before you can comment on or make changes to this bug.