Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Overly restrictive of data: URIs #70

Open
ndrezn opened this issue Mar 27, 2024 · 2 comments
Open

Overly restrictive of data: URIs #70

ndrezn opened this issue Mar 27, 2024 · 2 comments
Labels

Comments

@ndrezn
Copy link

ndrezn commented Mar 27, 2024

Hi folks, this package disallows data: URIs wholesale, which can be susceptible to the XSS exploit. However, there are cases where it's still a useful standard. Over in https://github.com/plotly/dash, we're using this project to sanitize URIs to protect against XSS, but some users have brought up that blanket prevention of data: can be overly restrictive (plotly/dash#2764).

This may not be an issue with this package per se, but the question is whether it is a reasonable approach to blanket disallow data: or whether there is a more fine-grained sanitation scheme that might allow certain kinds of valid data: URLs; maybe this is something maintainers of this package have thought about. Thanks!

@ndrezn
Copy link
Author

ndrezn commented Mar 27, 2024

For example, Mozilla has a broader definition of allowed data: URIs:

Whereas the following cases will be allowed:

  • User explicitly entering/pasting “data:…” into the address bar
  • Opening all plain text data files
  • Opening “data:image/*” in top-level window, unless it’s “data:image/svg+xml”
  • Opening “data:application/pdf” and “data:application/json”
  • Downloading a data: URL, e.g. ‘save-link-as’ of “data:…”

See: https://blog.mozilla.org/security/2017/11/27/blocking-top-level-navigations-data-urls-firefox-59/

@ndrezn ndrezn changed the title Overly restrictive of data: URLs Overly restrictive of data: URIs Mar 27, 2024
@ibooker
Copy link
Contributor

ibooker commented Aug 6, 2024

Hello,
We'll take a closer look at this issue.

Thanks for sharing.
(internal tracking BTWEB-1172)

@ibooker ibooker added the triaged label Aug 6, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants