Closed Bug 921423 Opened 11 years ago Closed 1 month ago

Implement Content Security Policy (CSP) for Mozilla Labs (mozillalabs.com)

Categories

(Websites :: mozillalabs.com, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: freddy, Unassigned)

References

Details

It seems like the current mozillalabs.com websites sends an X-Content-Security-Policy header, while it could send the new and shiny Content-Security-Policy header instead.
freddyb: it is also using deprecated "eval-script" and "inline-script" options. Need to change to "unsafe-inline" and "unsafe-eval" according to W3C std.
In addition, It whitelisted google-analytics.com domain. Is it safe to whitelist entire third-party domain? Or just whitelist the URL from that domain. I believe Google is doing their best to protect it's domain from being compromise by attacker and it will not send malicious code. IMO, Rather than whitelisting entire domain, only specific URL from third-party should be whitelisted in CSP policy.
How's this coming along?  X-Content-Security-Policy is long deprecated, and I was hoping we could move this to a more modern CSP policy.

Main problems I see:

- Use of deprecated directives (eval-script, inline-script)
- Use of http: sources
- Use default-src or default-src 'none'

Thanks, and let me know if you need any help crafting the policy.  :)
Summary: Mozillalabs.com uses the old CSP header (X-Content-Security-Policy) → Implement Content Security Policy (CSP) for Mozilla Labs (mozillalabs.com)

Th mozilla labs Website has been archivedand the project is no longer active

Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.