Side navigation
#12040 closed bug (fixed)
Opened July 08, 2012 03:31AM UTC
Closed February 28, 2013 05:41PM UTC
Last modified May 24, 2013 01:43PM UTC
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: |
Description
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.
Attachments (0)
Change History (9)
Changed July 08, 2012 03:32AM UTC by comment:1
| component: | unfiled → support |
|---|---|
| milestone: | None → 1.8 |
| priority: | undecided → low |
| status: | new → open |
Changed July 08, 2012 03:58AM UTC by comment:2
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
Changed July 08, 2012 10:26AM UTC by comment:3
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.
Changed July 08, 2012 08:00PM UTC by comment:4
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.
Changed August 10, 2012 05:56PM UTC by comment:5
| milestone: | 1.8 → 1.8.1 |
|---|
Changed August 27, 2012 01:49PM UTC by comment:6
| milestone: | 1.8.1 → 1.9 |
|---|
Changed December 09, 2012 02:40PM UTC by comment:7
| milestone: | 1.9 → None |
|---|
Changed February 28, 2013 05:41PM UTC by comment:8
| milestone: | None → 1.9.2 |
|---|---|
| resolution: | → fixed |
| status: | open → closed |
Changed May 24, 2013 01:43PM UTC by comment:9
| milestone: | 1.9.2 → 1.10/2.0 |
|---|
Bulk update to milestone 1.10/2.0