docs: ✏️ improve "Security Risks" section as per review

RISK_MATRIX.mdx

@@ -11,7 +11,8 @@ Below are some general themes to consider for the *Risk Matrix*:
 
 - What happens when your feature is used in a non-default space or a custom
   space?
-- What happens when there are multiple Kibana nodes using the same Elasticsearch cluster?
+- What happens when there are multiple Kibana nodes using the same Elasticsearch
+  cluster?
 - What happens when a plugin you depend on is disabled?
 - What happens when a feature you depend on is disabled?
 - Is your change working correctly regardless of `kibana.yml` configuration or
@@ -26,9 +27,9 @@ Below are some general themes to consider for the *Risk Matrix*:
   instances?
 - Does your feature need to be aware of running in a container?
 - Does the feature Work with security disabled, or fails gracefully?
-- Are there performance risks associated with your feature? Does it potentially access or create:
-  (1) many fields; (2) many indices; (3) lots of data; (4) lots of saved
-  objects; (5) large saved objects.
+- Are there performance risks associated with your feature? Does it potentially
+  access or create: (1) many fields; (2) many indices; (3) lots of data;
+  (4) lots of saved objects; (5) large saved objects.
 - Could this cause memory to leak in either the browser or server?
 - Will your feature still work if Kibana is run behind a reverse proxy?
 - Does your feature affect other plugins?
@@ -42,19 +43,20 @@ Below are some general themes to consider for the *Risk Matrix*:
 
 ## Security risks
 
-- XSS attacks—can user inject unescaped HTML on the page? (For example through
-  React's `dangerouslySetInnerHtml`, `Element.innerHTML`, `Element.outerHTML`).
-  Is all user input escaped?
-- CSRF attacks—are you not using the default Kibana HTTP service to
-  communicate with the server? If not ensure you configure correctly CSRF header
-  and talk with security team to review.
-- Remote code execution attacks—is your code doing something "highly"
-  dynamic? Such as: (1) usage of `eval` function; (2) usage of `vm` or
-  `child_process` Node.js modules; (3) usage of dynamic requires; (4) running
-  template interpolation such as Handlebars or Lodash `_.template`.
-- [Prototype pollution attacks](https://docs.google.com/document/d/19V-d9sb6IF-fbzF4iyiPpAropQNydCnoJApzSX5FdcI/edit?usp=sharing).
-- User input validation—are you validating user input beyond the default
-  HTTP server schema validation? Are you validating complex user input, such
-  as expression language or KQL?
-- Check for accidental reveal of sensitive information. It could be printed to
-  console through logs or errors.
+Check to ensure that best practices are used to mitigate common vulnerabilities:
+
+- Cross-site scripting (XSS)
+- Cross-site request forgery (CSRF)
+- Remote-code execution (RCE)
+- Server-side request forgery (SSRF)
+- Prototype pollution
+- Information disclosure
+- Tabnabbing
+
+In addition to these risks, in general, server-side input validation should be
+implemented as strictly as possible. Extra care should be taken when user input
+is used to construct URLs or data structures; this is a common source of
+injection attacks and other vulnerabilities. For more information on all of
+these topics, see [Security best practices][security-best-practices].
+
+[security-best-practices]: (https://www.elastic.co/guide/en/kibana/master/security-best-practices.html#security-best-practices).