W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] data: URI origin

From: Luis Marsnao <l0mars01@yahoo.com>
Date: Mon, 14 Mar 2011 13:27:23 -0700 (PDT)
Message-ID: <942025.45673.qm@web111410.mail.gq1.yahoo.com>
Can data: URIs be used insecurely?

I'm attempting to write a client-side script that processes a user selected file through an input element. Since the input element interface conceals the file: URI, the best solution I can think of is to access the file through the input element's interface, get its data: URI through readAsDataURL in FileAPI's FileReader interface, and process the data: URI. However, I get not-same-origin errors when I try to use this URI. Specifically, this happens when I try to use XMLHttpRequest to retrieve an XML resource with the data URI.

Is this correct?
http://www.w3.org/TR/html5/origin-0.html#origin-0 appears to suggest it: "If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier.", data URIs do not use server-based authorities, and opaque identifiers only have same origin with themselves.

Is there a better way to process files in a client-side script? I considered using blob: URIs, but the support is not yet there.

Can data: URIs be abused with the other same-origin policies in effect? I'm trying to imagine a situation where the data: URI origin policy is necessary for security. But I'm under the impression data: URIs literally are the resources they denote, and current policies allow input only from same-origin resources or the user, so scripts get input only from those sources. If that input literally is a resource, then that resource /should/ be treated as same-origin or from the user. Am I wrong?


      
Received on Monday, 14 March 2011 13:27:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC