Mandate a 'Security Considerations' section on MSCs (#4199)

And link to lists of possible problems to think about.
This is part of an effort to improve the overall security
of Matrix during the design process.

MSC_CHECKLIST.md

@@ -42,9 +42,9 @@ clarification of any of these points.
     - [ ] Proposal text
     - [ ] Potential issues
     - [ ] Alternatives
-    - [ ] Security considerations
     - [ ] Dependencies
 - [ ] Stable identifiers are used throughout the proposal, except for the unstable prefix section
     - [ ] Unstable prefixes [consider](README.md#unstable-prefixes) the awkward accepted-but-not-merged state
     - [ ] Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
 - [ ] Changes have applicable [Sign Off](CONTRIBUTING.md#sign-off) from all authors/editors/contributors
+- [ ] There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See [RFC3552](https://datatracker.ietf.org/doc/html/rfc3552) for things to think about, but in particular pay attention to the [OWASP Top Ten](https://owasp.org/www-project-top-ten/).

proposals/0000-proposal-template.md

@@ -85,14 +85,21 @@ idea.
 
 ## Security considerations
 
+**All proposals must now have this section, even if it is to say there are no security issues.**
+
+*Think about how to attack your proposal, using lists from sources like
+[OWASP Top Ten](https://owasp.org/www-project-top-ten/) for inspiration.*
+
 *Some proposals may have some security aspect to them that was addressed in the proposed solution. This
 section is a great place to outline some of the security-sensitive components of your proposal, such as
 why a particular approach was (or wasn't) taken. The example here is a bit of a stretch and unlikely to
 actually be worthwhile of including in a proposal, but it is generally a good idea to list these kinds
 of concerns where possible.*
 
-By having a template available, people would know what the desired detail for a proposal is. This is not
+MSCs can drastically affect the protocol. The authors of MSCs may not have a security background. If they
-considered a risk because it is important that people understand the proposal process from start to end.
+do not consider vulnerabilities with their design, we rely on reviewers to consider vulnerabilities. This
+is easy to forget, so having a mandatory 'Security Considerations' section serves to nudge reviewers
+into thinking like an attacker.
 
 ## Unstable prefix