Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Should remove report-uri from CSP if used in meta tag #148

Closed
jelhan opened this issue Jul 16, 2020 · 7 comments · Fixed by #172
Closed

Should remove report-uri from CSP if used in meta tag #148

jelhan opened this issue Jul 16, 2020 · 7 comments · Fixed by #172
Labels
Milestone

Comments

@jelhan
Copy link
Collaborator

jelhan commented Jul 16, 2020

The report-uri directive is only supported if CSP is delivered using HTTP header. It's not allowed if CSP is delivered using meta tag. If included in a CSP meta tag the browser throws an error. If the user configures the addon to deliver CSP both with HTTP header and meta tag he doesn't have any chance to prevent that error.

To avoid confusion we should strip the report-uri directive from CSP if included in meta tag. We should instead add a build time warning if user explicitly sets the report-uri directive but delivery option does not include 'header'.

@jelhan jelhan added the bug label Jul 16, 2020
@jelhan jelhan added this to the Release v2.0 milestone Jul 16, 2020
@rwjblue
Copy link
Member

rwjblue commented Jul 16, 2020

I think stripping when you are using both delivery mechanism is probably fine, but I have a couple questions:

  • why warn vs error when they are only using header delivery but have report-uri?
  • why would you use both delivery mechanisms?

@jelhan
Copy link
Collaborator Author

jelhan commented Jul 16, 2020

* why warn vs error when they are only using `header` delivery but have `report-uri`?

There shouldn't be a warning if delivery includes 'header' as having a report-uri directive is valid in that case. I guess you meant the opposite? In that case a warning seems to be more appropriate as the error would not affect build output. The report-uri directive would be stripped anyways from CSP in header. Only reason to warn at all is that developers may get confused by such a configuration.

* why would you use both delivery mechanisms?

Good question. I'm not aware of any actual use case. But it's currently supported by our configuration interface.

@rwjblue
Copy link
Member

rwjblue commented Jul 16, 2020

I guess you meant the opposite?

D'oh, sorry, yes.

@rwjblue
Copy link
Member

rwjblue commented Jul 16, 2020

OK, I'm sold. 😸

Warning seems fine (definitely better than what we do right now).

@sandstrom
Copy link
Collaborator

Good idea!

You probably know already, but report-uri is deprecated in favour of report-to[1].

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-uri

@jelhan
Copy link
Collaborator Author

jelhan commented Nov 23, 2020

This was partly addressed by #158. Before the addon was adding a report-uri directive even for CSP shipped by meta tag. After this change report-uri to report CSP violations in development server is only added to CSP shipped via HTTP header.

A report-uri directive included in CSP defined by the user is still not removed from CSP delivered via meta tag. But it should as a user does not have the possibility to define different CSP for delivery via meta and HTTP header. Additionally the CSP is applied as a meta tag in tests even if user hasn't configured the addon to deliver CSP via meta tag.

@sandstrom Thanks for mentioning deprecation of report-uri and addition of report-to as a replacement. But I think we should discuss required changes in this addon in a separate issue. Do you have time to open one?

@jelhan
Copy link
Collaborator Author

jelhan commented Nov 24, 2020

Reopening. I would still like to remove report-uri (and maybe later report-to) directives from CSP before shipping via meta tag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants