|
| 1 | +# Risk consideration |
| 2 | + |
| 3 | +When merging a new feature of considerable size or modifying an existing one, |
| 4 | +consider adding a *Risk Matrix* section to your PR in collaboration with other |
| 5 | +developers on your team and the QA team. |
| 6 | + |
| 7 | +Below are some general themes to consider for the *Risk Matrix*. (Feel free to |
| 8 | +add to this list.) |
| 9 | + |
| 10 | + |
| 11 | +## General risks |
| 12 | + |
| 13 | +- What happens when your feature is used in a non-default space or a custom |
| 14 | + space? |
| 15 | +- What happens when there are multiple Kibana nodes using the same Elasticsearch |
| 16 | + cluster? |
| 17 | +- What happens when a plugin you depend on is disabled? |
| 18 | +- What happens when a feature you depend on is disabled? |
| 19 | +- Is your change working correctly regardless of `kibana.yml` configuration or |
| 20 | + UI Setting configuration? (For example, does it support both |
| 21 | + `state:storeInSessionStorage` UI setting states?) |
| 22 | +- What happens when a third party integration you depend on is not responding? |
| 23 | +- How is authentication handled with third party services? |
| 24 | +- Does the feature work in Elastic Cloud? |
| 25 | +- Does the feature create a setting that needs to be exposed, or configured |
| 26 | + differently than the default, on the Elastic Cloud? |
| 27 | +- Is there a significant performance impact that may affect Cloud Kibana |
| 28 | + instances? |
| 29 | +- Does your feature need to be aware of running in a container? |
| 30 | +- Does the feature Work with security disabled, or fails gracefully? |
| 31 | +- Are there performance risks associated with your feature? Does it potentially |
| 32 | + access or create: (1) many fields; (2) many indices; (3) lots of data; |
| 33 | + (4) lots of saved objects; (5) large saved objects. |
| 34 | +- Could this cause memory to leak in either the browser or server? |
| 35 | +- Will your feature still work if Kibana is run behind a reverse proxy? |
| 36 | +- Does your feature affect other plugins? |
| 37 | +- If you write to the file system, what happens if Kibana node goes down? What |
| 38 | + happens if there are multiple Kibana nodes? |
| 39 | +- Are migrations handled gracefully? Does the feature affect old indices or |
| 40 | + saved objects? |
| 41 | +- Are you using any technologies, protocols, techniques, conventions, libraries, |
| 42 | + NPM modules, etc. that may be new or unprecedented in Kibana? |
| 43 | + |
| 44 | + |
| 45 | +## Security risks |
| 46 | + |
| 47 | +Check to ensure that best practices are used to mitigate common vulnerabilities: |
| 48 | + |
| 49 | +- Cross-site scripting (XSS) |
| 50 | +- Cross-site request forgery (CSRF) |
| 51 | +- Remote-code execution (RCE) |
| 52 | +- Server-side request forgery (SSRF) |
| 53 | +- Prototype pollution |
| 54 | +- Information disclosure |
| 55 | +- Tabnabbing |
| 56 | + |
| 57 | +In addition to these risks, in general, server-side input validation should be |
| 58 | +implemented as strictly as possible. Extra care should be taken when user input |
| 59 | +is used to construct URLs or data structures; this is a common source of |
| 60 | +injection attacks and other vulnerabilities. For more information on all of |
| 61 | +these topics, see [Security best practices][security-best-practices]. |
| 62 | + |
| 63 | +[security-best-practices]: https://www.elastic.co/guide/en/kibana/master/security-best-practices.html |
0 commit comments