Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#12040 closed bug (fixed)

Test against Content Security Policy (CSP)

Reported by: dmethvin Owned by:
Priority: low Milestone: 1.10/2.0
Component: support Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:


Ticket #11249 fixed a CSP issue with inline styles used for feature detects, but there is currently no unit test to ensure there are no regressions. It seems like we could do this with an iframed test where the web service returned the right Content-Security-Policy header. See http://www.html5rocks.com/en/tutorials/security/content-security-policy/ for more info.

Change History (9)

comment:1 Changed 11 years ago by dmethvin

Component: unfiledsupport
Milestone: None1.8
Priority: undecidedlow
Status: newopen

comment:2 Changed 11 years ago by anthonyryan1@…

There is in fact a csp.php in the test directory, however it looks severely dated to the current specification and would need updating.

In addition to this, I fear I'm skeptical that these php based test variants are actually run. It appears as though the xhtml one has been broken for a fairly long time.

If php based tests aren't the variant that's preferred right now, what is? I'd also like to point out that currently, there is no reliable way to catch CSP errors in javascript. The test written would need to be outside the scope of qUnit, and tested separately.

Let me know how you'd like to proceed and I'll come up with a test to whatever standard you're interested in.

While I'm at it, I'd also be interested in fixing the XHTML tests, as that directly affects projects I manage.

Anthony Ryan

comment:3 Changed 11 years ago by davidben

This wouldn't be a short-term solution, but I'll find the relevant WG and request a feature. There really should be better JavaScript access to CSP. At the very least it ought to be possible to query the current policy or something.

Perhaps the test could be based on report-uri somehow. There's a report-uri directive to trigger a request at a certain URL when the policy is violated. The server-side code could just keep some state and let you query it later. (If that's there, why didn't they do a DOM event too...) Asserting that this doesn't happen would likely be a bit wonky though since there's something asynchronous involved.

comment:4 Changed 11 years ago by anthonyryan1

That solution of storing a persistent state based on report-uri is already what I had in mind (and written), afraid I may not have explained it clearly.

Right now though, I have a working patch written in PHP (the language I saw already in use). I just need to know what the preferred webserver language would be (PHP, Node?), and whether cookies or flatfiles are preferred for persistent data. Whatever language is decided, would be required everywhere tests are run, so I don't want to make any assumptions.

comment:5 Changed 11 years ago by dmethvin


comment:6 Changed 11 years ago by dmethvin


comment:7 Changed 11 years ago by dmethvin

Milestone: 1.9None

comment:9 Changed 10 years ago by dmethvin


Bulk update to milestone 1.10/2.0

Note: See TracTickets for help on using tickets.