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.