github.com/cozy/cozy-stack@v0.0.0-20240603063001-31110fa4cae1/docs/security.md (about) 1 [Table of contents](README.md#table-of-contents) 2 3 # Security 4 5 ## Checklist 6 7 1. Strong security is centered on the user 8 1. Defense in depth is still worthy 9 1. Have a strict control of all the accesses to the Cozy 10 1. Protect client-side apps by default 11 1. Don't trust inputs, always sanitize them 12 1. Encryption is not the solution to all the problems, but it helps 13 1. Use standards (https, OAuth2) 14 1. Have a reliable way to deploy, with sane defaults 15 1. No one is perfect, code must be reviewed 16 1. Be open to external contributors 17 18 ## Rationale 19 20 ### Strong security is centered on the user 21 22 For systems well designed, the user is often the weakest link in the security 23 chain. Engineers have a tendancy to overestimate the technical risks and 24 underestimate the human interactions. It doesn't mean that we can avoid 25 technical measures. But it's very important to take in account the possible 26 behaviour of the user. That means that adding a text to explain him/her the 27 consequences of a click on a button can increase the security a lot much than 28 forcing him/her to do things. For example, forcing users to change regulary 29 their password makes them choose passwords that are a lot weaker (but easier for 30 them to remember). 31 32 [![Security XKCD](https://imgs.xkcd.com/comics/security.png)](https://xkcd.com/538/) 33 34 ### Defense in depth is still worthy 35 36 Also known as layered defense, defense in depth is a security principle where 37 single points of complete compromise are eliminated or mitigated by the 38 incorporation of a series or multiple layers of security safeguards and 39 risk-mitigation countermeasures. Have diverse defensive strategies, so that if 40 one layer of defense turns out to be inadequate, another layer of defense will 41 hopefully prevent a full breach. 42 43 ### Have a strict control of all the accesses to the Cozy 44 45 All the requests to the cozy stack have a strict access control. It is based on 46 several informations: 47 48 - Is the user connected? 49 - What is the application that makes this request? 50 - What are the permissions for this application? 51 - Which grant is used, in particular for applications with public pages? 52 - What are the permissions for this grant? 53 54 More informations [here](apps.md). 55 56 ### Protect client-side apps by default 57 58 This is mostly applying the state of the art: 59 60 - Using HTTPS, with HSTS. 61 - Using secure, httpOnly, 62 [sameSite](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) 63 cookies to avoid cookies theft or misuse. 64 - Using a Content Security Policy (CSP). 65 - Using X-frame-options http header to protect against click-jacking. 66 67 But we will use a CSP very restrictive by default (no access to other web 68 domains for example). 69 70 ### Don't trust inputs, always sanitize them 71 72 If we take 73 [the OWASP top 10 vulnerabilities](https://www.owasp.org/index.php/Top_10_2013-Top_10), 74 we can see that a lot of them are related to trusting inputs. It starts with the 75 first one, injections, but it goes also to XSS and unvalidated forwards (in 76 OAuth2 notably). Always sanitizing inputs is a good pratice that improves 77 security, but has also some nice effects like helping developers discover hidden 78 bugs. 79 80 ### Encryption is not the solution to all the problems, but it helps 81 82 Some data are encrypted before being saved in CouchDB (passwords for the 83 accounts for example). Encrypting everything has some downsides: 84 85 - It's not possible to index encryped documents or do computations on the 86 encrypted fields in reasonable time 87 ([homomorphic encryption](https://en.wikipedia.org/wiki/Homomorphic_encryption) 88 is still an open subject). 89 - Having more encrypted data can globally weaken the encryption, if it's not 90 handled properly. 91 - If the encryption key is lost or a bug happen, the data is lost with no way 92 to recover them. 93 94 So, we are more confortable to encrypt only some fields. And later, when we will 95 have more experience and feedbacks from the user, extend the encryption to more 96 fields. 97 98 We are also working with [SMIS](https://project.inria.fr/smis/), a research lab, 99 to find a way to securely store and backup the encryption keys. 100 101 ### Use standards (https, OAuth2) 102 103 Standards like https and OAuth2 had a lot of eyes to look at them, and are 104 therefore more robust. Reinventing the wheel can be valuable for some things. 105 But for security, the cost is very high and only some very particular 106 constraints can justify such an high cost. Cozy don't have these constraints, so 107 we will stick to the standards. 108 109 ### Have a reliable way to deploy, with sane defaults 110 111 It's important that deploying a cozy is well documented, doesn't require too 112 many steps and can be automatized. An error on the installation can have 113 dramatic effects, like the database being leaked on internet. So, we need to 114 really take care of the devops experience. In particular, having sane defaults 115 for the configuration will help to minimize the number of things he/she has to 116 do, and such the number of places where he/she can make faux pas. 117 118 ### No one is perfect, code must be reviewed 119 120 No code is directly pushed to the master branch in git. It has to be reviewed by 121 at least one member of the core team (ideally the whole team), and this person 122 can't be the author of the change. Even the best developers can make mistakes, 123 and we don't pretend to be them. Our force is to work as team. 124 125 ### Be open to external contributors 126 127 Our code is Open Source, external contributors can review it. If they (you?) 128 find a weakness, please contact us by sending an email to security AT 129 cozycloud.cc. This is a mailing-list specially setup for responsible disclosure 130 of security weaknesses in Cozy. We will respond in less than 72 hours. 131 132 When a security flaw is found, the process is the following: 133 134 - Make a pull-request to fix (on our private git instance) and test it. 135 - Deploy the fix on cozycloud.cc 136 - Publish a new version, announce it on 137 [the forum](https://forum.cozy.io/c/english/news/52) 138 as a security update and on the mailing-lists. 139 - 15 days later, add the details on the forum.