report-uri directive of Content-Security-Policy does not follow RFC-3986




6 years ago
5 years ago


(Reporter: sbehrens, Unassigned)


(Blocks 1 bug)

28 Branch

Firefox Tracking Flags

(Not tracked)




6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

Specifically a report-uri in a valid CSP policy using a different port from the originating document.  


CSP policy is loaded on and the following is sent in a response:

Content-Security-Policy: default-src 'self'; report-uri

Actual results:

Warning message is displayed in Console:

Content Security Policy: can't use report URI with different port from originating document:

Expected results:

The report should have been sent to the host and port specified in the report-url.  

According to both the CSP 1.0 final document and CSP 1.1 draft document, RFC-3968 is how report-uri syntax should interpreted.  The following was pulled from the CSP 1.0 specification:  

The report-uri directive specifies a URI to which the user agent sends reports about policy violation. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "report-uri"
directive-value   = uri-reference *( 1*WSP uri-reference )
uri-reference     = <URI-reference from RFC 3986>

If we look at RFC 3968, it says that a URI can have a port value.  I read the whole section on report-uri in CSP 1.0 and there is no mention that the report-uri must match the same port.  Since it is not in the specification, it should not behave the way it is currently.  THis is making it impossible for me to setup a report aggregator on a non standard report for all the sites I manage that use CSP.
Blocks: CSP
Component: Untriaged → Security
Product: Firefox → Core
Scott or anyone else, I just came across this issue while cleaning up some Firefox 28 unconfirmed bugs. Is this still the case? I could go set up a site and dig into the current CSP but it seems best to ask people who likely already know.
Flags: needinfo?(sbehrens)
OS: Mac OS X → All
Hardware: x86 → All
This might be a dupe of bug 843311 which is fixed in 29.

Comment 3

5 years ago
Hey Ian,

It's similar to bug 84331 except with this issue it's not the SCHEME mismatch that's causing the issue, it's the port number. 

If you are sending CSP violations to a host that is listening on a different port number, the reports do not get sent.
Flags: needinfo?(sbehrens)
Summary: report-uri directive of Content-Secuirty-Policy does not follow RFC-3986 → report-uri directive of Content-Security-Policy does not follow RFC-3986
Component: Security → DOM: Security
HI there. This bug is still showing up in my triage queues as UNCONFIRMED. Sid, is there anyone who we should need-info into this bug to move it along and get it resolved one way or the other? Thanks!
Flags: needinfo?(sstamm)
Scott, is this still a problem on nightly?
Flags: needinfo?(sstamm) → needinfo?(sbehrens)
Matt, could you take a look at this to see if it's still a problem in Nightly? (Given that I think Sid thinks it would be a problem if it were a problem.)  :)
Flags: needinfo?(mwobensmith)
The error appears in Fx28 but not in Fx29 and onwards. As Sid says in comment 4 - it was fixed in that patch.

Scott, try this again and confirm. Do you still see an error message in Fx29, and does the report get sent when its destination host contains a different port?
Flags: needinfo?(mwobensmith)
I'm gonna close this WORKSFORME since Matt indicates it is already fixed.  Scott, please ping us or reopen this bug if it's still a problem.
Last Resolved: 5 years ago
Flags: needinfo?(sbehrens)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.