Fixing typo errors in the documentation (#9432)

docs/contributing/security.md

@@ -13,7 +13,7 @@ Once you've submitted an issue via email, you should receive an acknowledgement
 
 If you want to send an encrypted email (optional), the public key ID for <security@wagtail.org> is `0xbed227b4daf93ff9`, and this public key is available from most commonly-used keyservers.
 
-Django security issues should be reported directly to the Django Project, following [Django\'s security policies](https://docs.djangoproject.com/en/dev/internals/security/) (upon which Wagtail\'s own policies are based).
+Django security issues should be reported directly to the Django Project, following [Django's security policies](https://docs.djangoproject.com/en/dev/internals/security/) (upon which Wagtail's own policies are based).
 
 ## Supported versions
 
@@ -37,10 +37,10 @@ There is no fixed period of time by which a confirmed security issue will be res
 The reporter of the issue will receive notification of the date on which we plan to take the issue public.
 On the day of disclosure, we will take the following steps:
 
-1. Apply the relevant patch(es) to Wagtail\'s codebase.
+1. Apply the relevant patch(es) to Wagtail's codebase.
    The commit messages for these patches will indicate that they are for security issues, but will not describe the issue in any detail; instead, they will warn of upcoming disclosure.
-2. Issue the relevant release(s), by placing new packages on [the Python Package Index](https://pypi.org/project/wagtail/), tagging the new release(s) in Wagtail\'s GitHub repository and updating Wagtail\'s [release notes](../releases/index).
-3. Post a public entry on [Wagtail\'s blog](https://wagtail.org/blog/), describing the issue and its resolution in detail, pointing to the relevant patches and new releases, and crediting the reporter of the issue (if the reporter wishes to be publicly identified).
+2. Issue the relevant release(s), by placing new packages on [the Python Package Index](https://pypi.org/project/wagtail/), tagging the new release(s) in Wagtail's GitHub repository and updating Wagtail's [release notes](../releases/index).
+3. Post a public entry on [Wagtail's blog](https://wagtail.org/blog/), describing the issue and its resolution in detail, pointing to the relevant patches and new releases, and crediting the reporter of the issue (if the reporter wishes to be publicly identified).
 4. Post a notice to the [Wagtail support forum](https://groups.google.com/g/wagtail) and Twitter feed ([\@WagtailCMS](https://twitter.com/wagtailcms)) that links to the blog post.
 
 If a reported issue is believed to be particularly time-sensitive -- due to a known exploit in the wild, for example -- the time between advance notification and public disclosure may be shortened considerably.
@@ -51,4 +51,4 @@ In various places Wagtail provides the option to export data in CSV format, and
 
 Since the CSV format has no concept of formulae or macros, there is also no agreed-upon convention for escaping data to prevent it from being interpreted in that way; commonly-suggested approaches such as prefixing the field with a quote character would corrupt legitimate data (such as phone numbers beginning with '+') when interpreted by software correctly following the CSV specification.
 
-Wagtail's data exports default to XLSX, which can be loaded into spreadsheet software without any such issues. This minimises the risk of a user handling CSV files insecurely, as they would have to explicitly choose CSV over the more familiar XLSX format.
+Wagtail's data exports default to XLSX, which can be loaded into spreadsheet software without any such issues. This minimises the risk of a user handling CSV files insecurely, as they would have to explicitly choose CSV over the more familiar XLSX format.