This guide will give you a quick heads-up on important security topics to keep in mind as you work on projects which face the public internet like Treeherder.
Involving the Security Team¶
The security teams can be easily involved by setting the
sec-review flag to
? in Bugzilla. It is highly encouraged to do that early in the development
process. For bigger projects the Security Review Process should be taken into
account, so that security considerations are resolved before the day of
deployment dawns. If you have small questions, feel free to flag someone for
feedback or ask in #security on IRC.
X-Frame-Options (XFO) is a security header (i.e. in your HTTP response) that states whether your site should be framed or not. For several reasons laid out in this blog post, you should default to DENY.
If you do need to be framed, you can restrict this to web pages in the same origin (people sometimes think “same domain”, but it’s actually the protocol, domain name and port forming the security scope of a website). There are detailed docs about XFO on MDN and there are additional resources that show you how to set up X-Frame-Options in your Django and NodeJS projects.
Content Security Policy¶
When building web applications, it is best to incorporate Content Security Policy (CSP) early into the development process. You may find it substantially harder to apply CSP to existing projects because of the way it restrains the capabilities of your code.
Content Security Policy (CSP) is a security header which is able to mitigate some client-side attacks on web applications, like Cross-Site Scripting (XSS). Think of CSP as a whitelist of resources which are allowed to be embedded into your HTML documents. As CSP does not prevent flaws from being exploited but merely mitigates the effects, you should never solely rely on it. CSP 1.1 is already being drafted at the W3C, but you should focus on CSP 1.0 - mainly because of its wide adoption among browsers. Head on over to MDN for more information on this topic.
* wildcards pose a security risk and should be completely avoided in
critical directives like
If you are unsure about a certain case, members of the web security team
will gladly help (See Involving the Security Team).
To avoid CSP problems, follow these guidelines:
<script>code</script>), inline event handlers (e.g.
- Don’t use inline CSS code. This includes inline style elements
<style>code</style>) and inline style attributes (
- Don’t use
Function('string')()or any other eval-like construct.
Here are some strategies for avoiding common CSP errors:
|Inline script elements:|
|Should go into a JS file.|
|Inline event handlers:|
|Attach event handler in an external JS file (addEventListener) or let event bubbling work for you (e.g. JQuery’s $.live).|
|JS pseudo protocol:|
|Attach click event handler to the node (see above)|
|Inline style elements:|
|These can be easily put into an external CSS file|
|Inline style attributes:|
|Add classes or IDs to your markup and handle those in an external CSS file|