Bug 208200 - A SecurityError is thrown when opening indexedDB in an iframe within a same subdomain tree
Summary: A SecurityError is thrown when opening indexedDB in an iframe within a same s...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Website Storage (show other bugs)
Version: Safari 13
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://a.indigital.io
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-02-25 08:52 PST by Benoit F.
Modified: 2023-09-01 08:34 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benoit F. 2020-02-25 08:52:58 PST
If you open an IndexedDB connection in an iframe, it throws a SecurityError, that is completely normal if you are in a cross-origin context.

But what if you are in a domain, say "a.example.com", and you embed an iframe with "src" equal to "b.a.example.com".

The standard (https://html.spec.whatwg.org/multipage/origin.html#relaxing-the-same-origin-restriction) states that you can relax the same-origin restriction that would usually by applied by setting the "document.domain" to the same Second-Level Domain (SLD) in both parent and child contexts.

In my example, setting "document.domain" to "example.com" in the top window and the iframe window is legit and should put both in a same-origin context.

Here is a reproduction link (http://a.indigital.io) with a minimalist context. The iframe loads http://b.a.indigital.io, which is a subdomain of the opening window.
Comment 1 Radar WebKit Bug Importer 2022-02-01 11:19:49 PST
<rdar://problem/88339063>
Comment 2 Anne van Kesteren 2023-09-01 08:33:41 PDT
That is still cross-origin, though we might change that at some point to use same-site instead. Relaxing the restriction only applies to a select set of features and this is not one of them.

Nevertheless, these days you should not get an exception, but rather partitioned storage.