Fix various spelling mistakes across most of the cheat sheets

.github/ISSUE_TEMPLATE/update_cheatsheet_proposal.md

@@ -1,6 +1,6 @@
 ---
 name: update_cheatsheet_proposal
-about: Used to create a proposal to update/refactor a exsiting cheat sheet
+about: Used to create a proposal to update/refactor a existing cheat sheet
 title: 'Cheat sheet update/refactor proposal: [PUT_TARGET_CS_NAME_HERE]'
 labels: ACK_WAITING, UPDATE_CS, HELP_WANTED
 assignees: ''

CONTRIBUTING.md

@@ -11,7 +11,7 @@ Follow these steps:
 1. Create an new [Issue](https://github.com/OWASP/CheatSheetSeries/issues/new/choose) using either:
    - The `new_cheatsheet_proposal` template if you want to propose a new cheat sheet.
    - The `update_cheatsheet_proposal` template if you want to modify a existing cheat sheet.
-2. After a discution on the topic/update and if the proposal is accepted by the project leaders then:
+2. After a discussion on the topic/update and if the proposal is accepted by the project leaders then:
     1. Clone this GitHub repository.
     2. Either:
       - Create the cheat sheet using the dedicated [template](templates/New_CheatSheet.md) in case of a new cheat sheet.
@@ -37,7 +37,7 @@ Follow these steps:
 2. Ensure that the markdown file you have created/modified do not have any deadlinks. You can verify that by using this [plugin](https://www.npmjs.com/package/markdown-link-check), if you cannot use this plugin then, at least, verify that all the links are valid before to push:
     1. Install [NodeJS](https://nodejs.org/en/download/) to install NPM.
     2. Install the validation plugin via the command `npm install -g markdown-link-check`
-    3. Use this commmand (from the repository root folder) on your markdown file to verify the presence of any deadlinks: 
+    3. Use this command (from the repository root folder) on your markdown file to verify the presence of any deadlinks: 
 
 ```bash
 $ markdown-link-check -c .markdownlinkcheck.json [MD_FILE]

CONTRIBUTOR-V1.md

@@ -1,4 +1,4 @@
-# Contributors to the intial version of the project
+# Contributors to the initial version of the project
 
 If you want to modify something regarding the mention made to you (typo/link to your profile/etc), feel free to submit a PR with the expected content. Same approach if you think that we have forgotten someone.
 
@@ -79,7 +79,7 @@ Sorting applied on the name is an alphabetical one.
 **[Cross Site Scripting Prevention Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md)**
 * Jeff Williams - jeff.williams@contrastsecurity.com
 * Jim Manico - jim@owasp.org
-* Neil Mattatall - neil@owasp.org
+* Neil Matatall - neil@owasp.org
 
 **[Cryptographic Storage Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md)**
 * David Rook - david.a.rook@gmail.com
@@ -224,7 +224,7 @@ Sorting applied on the name is an alphabetical one.
 **[Query Parameterization Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets/Query_Parameterization_Cheat_Sheet.md)**
 * Dave Wichers - dave.wichers@owasp.org
 * Jim Manico - jim@owasp.org
-* Neil Matatal - neil@owasp.org
+* Neil Matatall - neil@owasp.org
 
 **[REST Assessment Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets/REST_Assessment_Cheat_Sheet.md)**
 * Ofer Shezaf - ofer@shezaf.com

README.md

@@ -30,7 +30,7 @@ Links:
 - [Offline website](#offline-website)
 - [Project leaders](#project-leaders)
 - [Core team](#core-team)
-- [PR usage for core commiters](#pr-usage-for-core-commiters)
+- [PR usage for core committers](#pr-usage-for-core-committers)
 - [Project logo](#project-logo)
 - [Folders](#folders)
 - [License](#license)
@@ -118,7 +118,7 @@ The project's official logo files are hosted [here](https://github.com/OWASP/owa
 
 **assets**: 
 * Contains the assets used by the cheat sheets (images, PDF's, ZIP files etc.).
-    * Naming convention is `[CHEAT_CHEET_MARKDOWN_FILE_NAME]_[IDENTIFIER].[EXTENSION]`
+    * Naming convention is `[CHEAT_SHEET_MARKDOWN_FILE_NAME]_[IDENTIFIER].[EXTENSION]`
     * Use `PNG` format for the images.
 
 **scripts**:

cheatsheets/AJAX_Security_Cheat_Sheet.md

@@ -2,7 +2,7 @@
 
 This document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies.
 
-## Client Side (Javascript)
+## Client Side (JavaScript)
 
 ### Use .innerText instead of .innerHtml
 

cheatsheets/Authorization_Testing_Automation.md

@@ -1,6 +1,6 @@
 # Introduction
 
-Authorizations definition and implementation is one of the important protection measure of an application. They are defined in the creation phase of the project and, even if authorization issues are found when the application is initially released and submitted to a security audit before to go live, the most signicant number of issues related to authorization came in the maintenance lifetime of the application.
+Authorizations definition and implementation is one of the important protection measure of an application. They are defined in the creation phase of the project and, even if authorization issues are found when the application is initially released and submitted to a security audit before to go live, the most significant number of issues related to authorization came in the maintenance lifetime of the application.
 
 This situation is often explained by the fact that features are added/modified and no review of the authorizations was performed on the application before the publishing of the new release, for cost or time issue reason.
 
@@ -18,13 +18,13 @@ During a test of an authorization, a **Logical Role** is also called a **Point O
 
 This article describe a proposition of implementation in order to automate the tests of an *authorization matrix*.
 
-This article use the assumption that 2 dimensions are used to represents an authorization for the technical proposition decribed and take as example a application exposing REST services.
+This article use the assumption that 2 dimensions are used to represents an authorization for the technical proposition described and take as example a application exposing REST services.
 
 The objective is to provide starting ideas/hints in order to create a tailored way of testing of the authorization matrix for the target application.
 
 # Proposition
 
-In order to achieve the full automation of the evaluation of the *authorization matrix*, the folowing actions has been performed:
+In order to achieve the full automation of the evaluation of the *authorization matrix*, the following actions has been performed:
 
 1.  Formalize the authorization matrix in a pivot format file allowing:
     1.  The processing by a program in a easy way.
@@ -126,7 +126,7 @@ This is an example of the XML used to represents the authorization:
 
 ## Integration tests
 
-Integration tests are implemented using a maximum of factorized code and one test case by **Point Of View (POV)** has been created in order to group the verifications by profile of access level (logical role) and faciliate the rendering/identification of the errors.
+Integration tests are implemented using a maximum of factorized code and one test case by **Point Of View (POV)** has been created in order to group the verifications by profile of access level (logical role) and facilitate the rendering/identification of the errors.
 
 Parsing, object mapping and access to the authorization matrix information has been implemented using XML marshalling/unmarshalling built-in features provided by the technology used to implements the tests (JAXB here) in order to limit the code to the one in charge of performing the tests.
 
@@ -396,7 +396,7 @@ Access issues detected using the BASIC USER point of view:
 
 # Rendering of the authorization matrix for audit / review
 
-Even if the authorization matrix is stored in a human readable format (XML), it can be interesting to provide an on-the-fly rendering representation of the XML file in order to facilitate the review, audit and discution about the authorization matrix in order to spot potential inconsistencies.
+Even if the authorization matrix is stored in a human readable format (XML), it can be interesting to provide an on-the-fly rendering representation of the XML file in order to facilitate the review, audit and discussion about the authorization matrix in order to spot potential inconsistencies.
 
 The Following XSL stylesheet can be used:
 

cheatsheets/Bean_Validation_Cheat_Sheet.md

@@ -435,7 +435,7 @@ public class ReviewController {
 
 ## Cascading Constraints
 
-Validating one bean is a good start, but often, beans are nested or in a complete graph of beans. To validate that graph in one go, apply cascading valiation with [@Valid](http://docs.jboss.org/hibernate/validator/5.2/reference/en-US/html/ch03.html#_cascaded_validation)
+Validating one bean is a good start, but often, beans are nested or in a complete graph of beans. To validate that graph in one go, apply cascading validation with [@Valid](http://docs.jboss.org/hibernate/validator/5.2/reference/en-US/html/ch03.html#_cascaded_validation)
 
 ## Additional Constraints
 

cheatsheets/C-Based_Toolchain_Hardening.md

@@ -54,7 +54,7 @@ Debug build should also define `DEBUG`, and ensure `NDEBUG` is not defined. `NDE
 
 In addition, you should use other relevant flags, such as `-fno-omit-frame-pointer`. Ensuring a frame pointer exists makes it easier to decode stack traces. Since debug builds are not shipped, its OK to leave symbols in the executable. Programs with debug information do not suffer performance hits. See, for example, [How does the gcc -g option affect performance?](http://gcc.gnu.org/ml/gcc-help/2005-03/msg00032.html)
 
-Finally, you should ensure your project includes additional diagnostic libraries, such as `dmalloc` and [Address Sanitizer](http://code.google.com/p/address-sanitizer/). A comparison of some memory checking tools can be found at [Comparison Of Memory Tools](http://code.google.com/p/address-sanitizer/wiki/ComparisonOfMemoryTools). If you don't include additional diagostics in debug builds, then you should start using them sinces its OK to find errors you are not looking for.
+Finally, you should ensure your project includes additional diagnostic libraries, such as `dmalloc` and [Address Sanitizer](http://code.google.com/p/address-sanitizer/). A comparison of some memory checking tools can be found at [Comparison Of Memory Tools](http://code.google.com/p/address-sanitizer/wiki/ComparisonOfMemoryTools). If you don't include additional diagnostics in debug builds, then you should start using them sinces its OK to find errors you are not looking for.
 
 ### Release Builds
 

cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.md

@@ -23,7 +23,7 @@ The remainder of this cheat sheet briefly explains the bulleted, actionable item
 
 You should support three build configurations. First is *Debug*, second is *Release*, and third is *Test*. One size does **not** fit all, and each speaks to a different facet of the engineering process. You will use a debug build while developing, your continuous integration or build server will use test configurations, and you will ship release builds.
 
-1970's K&R code and one size fits all flags are from a bygone era. Processes have evolved and matured to meet the challenges of a modern landscape, including threats. Because tools like Autconfig and Automake [do not support the notion of build configurations](https://lists.gnu.org/archive/html/automake/2012-12/msg00019.html), you should prefer to work in an Integrated Develop Environments (IDE) or write your makefiles so the desired targets are supported. In addition, Autconfig and Automake often ignore user supplied flags (it depends on the folks writing the various scripts and templates), so you might find it easier to again write a makefile from scratch rather than retrofitting existing auto tool files.
+1970's K&R code and one size fits all flags are from a bygone era. Processes have evolved and matured to meet the challenges of a modern landscape, including threats. Because tools like Autoconfig and Automake [do not support the notion of build configurations](https://lists.gnu.org/archive/html/automake/2012-12/msg00019.html), you should prefer to work in an Integrated Develop Environments (IDE) or write your makefiles so the desired targets are supported. In addition, Autoconfig and Automake often ignore user supplied flags (it depends on the folks writing the various scripts and templates), so you might find it easier to again write a makefile from scratch rather than retrofitting existing auto tool files.
 
 ## Debug Builds
 
@@ -82,7 +82,7 @@ You should consider a clean compile as a security gate. If you find its painful
 
 When compiling programs with GCC, you should use the following flags to help detect errors in your programs. The options should be added to `CFLAGS` for a program with C source files, and `CXXFLAGS` for a program with C++ source files. Objective C developers should add their warnings to `CFLAGS`: `-Wall` `-Wextra` `-Wconversion` `(or` `-Wsign-conversion),` `-Wcast-align,` `-Wformat=2` `-Wformat-security,` `-fno-common,` `-Wmissing-prototypes,` `-Wmissing-declarations,` `-Wstrict-prototypes,` `-Wstrict-overflow,` `and` `-Wtrampolines`. C++ presents additional opportunities under GCC, and the flags include `-Woverloaded-virtual,` `-Wreorder,` `-Wsign-promo,` `-Wnon-virtual-dtor` and possibly `-Weffc++`. Finally, Objective C should include `-Wstrict-selector-match` and `-Wundeclared-selector`.
 
-For a Microsoft platform, you should use: `/W4`, `/Wall`, and `/analyze`. If you don't use `/Wall`, Microsoft recomends using `/W4` and enabling C4191, C4242, C4263, C4264, C4265, C4266, C4302, C4826, C4905, C4906, and C4928. Finally, `/analyze` is Enterprise Code Analysis, which is freely available with the [Windows SDK for Windows Server 2008 and .NET Framework 3.5 SDK](https://www.microsoft.com/en-us/download/details.aspx?id=21) (you don't need Visual Studio Enterprise edition).
+For a Microsoft platform, you should use: `/W4`, `/Wall`, and `/analyze`. If you don't use `/Wall`, Microsoft recommends using `/W4` and enabling C4191, C4242, C4263, C4264, C4265, C4266, C4302, C4826, C4905, C4906, and C4928. Finally, `/analyze` is Enterprise Code Analysis, which is freely available with the [Windows SDK for Windows Server 2008 and .NET Framework 3.5 SDK](https://www.microsoft.com/en-us/download/details.aspx?id=21) (you don't need Visual Studio Enterprise edition).
 
 For additional details on the GCC and Windows options and flags, see *[GCC Options to Request or Suppress Warnings](http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html)*, *["Off By Default" Compiler Warnings in Visual C++](http://blogs.msdn.com/b/vcblog/archive/2010/12/14/off-by-default-compiler-warnings-in-visual-c.aspx)*, and *[Protecting Your Code with Visual C++ Defenses](http://msdn.microsoft.com/en-us/magazine/cc337897.aspx)*.
 

cheatsheets/Clickjacking_Defense_Cheat_Sheet.md

@@ -166,7 +166,7 @@ Some frame busting techniques navigate to the correct page by assigning a value
 **Victim frame busting code:**
 
 ```javascript
-if(top.location != self.locaton) {
+if(top.location != self.location) {
     parent.location = self.location;
 }
 ```

cheatsheets/Content_Security_Policy_Cheat_Sheet.md

@@ -92,7 +92,7 @@ Reporting directives deliver violations of prevented behaviors to specified loca
 - `report-uri` directive is deprecated by `report-to`, which is a URI that the reports are sent to.
   - Goes by the format of: `Content-Security-Policy: report-uri https://example.com/csp-reports`
 
-In order to ensure backward compatibility, use the 2 directives in conjonction. Whenever a browser supports `report-to`, it will ignore `report-uri`. Otherwise, `report-uri` will be used.
+In order to ensure backward compatibility, use the 2 directives in conjunction. Whenever a browser supports `report-to`, it will ignore `report-uri`. Otherwise, `report-uri` will be used.
 
 ## Special Directive Sources
 

cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.md

@@ -101,7 +101,7 @@ In order to protect the value of the source password being searched for, Pwned P
 
 ## Notify users about unusual security events
 
-When suspicious or unusal activity is detected, it may be appropriate to notify or warn the user. However, care should be taken that the user does not get overwhelmed with a large number of notifiations that are not important to them, or they will just start to ignore or delete them.
+When suspicious or unusual activity is detected, it may be appropriate to notify or warn the user. However, care should be taken that the user does not get overwhelmed with a large number of notifications that are not important to them, or they will just start to ignore or delete them.
 
 For example, it would generally not be appropriate to notify a user that there had been an attempt to login to their account with an incorrect password. However, if there had been a login with the correct password, but which had then failed the subsequent MFA check, the user should be notified so that they can change their password.
 

cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md

@@ -119,7 +119,7 @@ Though the technique of mitigating tokens is widely used (stateful with synchron
 - Write a hook (that would capture the traffic and add tokens to CSRF vulnerable resources before rendering to customers) in your organizational web rendering frameworks. Because it is hard to analyze when a particular response is doing any state change (and thus needing a token), you might want to include tokens in all CSRF vulnerable resources (ex: include tokens in all POST responses). This is one recommended approach, but you need to consider the performance costs it might incur.
 - Get the tokens automatically added on the client side when the page is being rendered in user's browser, with help of a client side script (this approach is used by [CSRF Guard](https://www.owasp.org/index.php/CSRF_Guard)). You need to consider any possible JavaScript hijacking attacks.
 
-We recommend researching if the framework you are using has an option to achieve CSRF protection by default before trying to build your custom auto tokening system. For example, .NET has an [in-built protection](https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1) that adds token to CSRF vulnerable resources. You are responsible for proper configuration (such as key management and token management) before using these in-built CSRF protections that do auto tokening to CSRF vulnerable resources.
+We recommend researching if the framework you are using has an option to achieve CSRF protection by default before trying to build your custom token generating system. For example, .NET has [built-in protection](https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1) that adds a token to CSRF vulnerable resources. You are responsible for proper configuration (such as key management and token management) before using these built-in CSRF protections that generate tokens to guard CSRF vulnerable resources.
 
 ## Login CSRF