Fix typos discovered by codespell (#726)

.github/workflows/build-and-deploy-website.yml

@@ -49,7 +49,7 @@ jobs:
       uses: actions/checkout@v1
     - name: Install dependencies
       run: sudo apt-get install -y unzip zip
-    - name: Swith to offline website (gh-pages) branch
+    - name: Switch to offline website (gh-pages) branch
       run: git checkout gh-pages
     - name: Remove previous version website files
       run: |

cheatsheets/Access_Control_Cheat_Sheet.md

@@ -81,7 +81,7 @@ The areas of caution while using ABAC are:
 
 - Consider that good ABAC only works in scenarios where data is relatively static, or not frequently being created or changing in any way.
 - ABAC works best when there are clear data owners who can permit others access to the data intentionally.
-- Avoid starting ABAC when there is any chance new data can not be given a data owner to grant access, or when you find that data access defaults are overly permissive to excess of users or when the default attribute covers an excess fo data.
+- Avoid starting ABAC when there is any chance new data can not be given a data owner to grant access, or when you find that data access defaults are overly permissive to excess of users or when the default attribute covers an excess of data.
 
 ### Organization-Based Access Control (OrBAC)
 

cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.md

@@ -4,7 +4,7 @@ This document proposes a standard vocabulary for logging security events. The in
 
 ## Overview
 
-Each year IBM Security comissions the Ponemon Institute to survey companies around the world for information related to security breaches, mitigation, and the associated costs; the result is called the Cost of a Data Breach Report.
+Each year IBM Security commissions the Ponemon Institute to survey companies around the world for information related to security breaches, mitigation, and the associated costs; the result is called the Cost of a Data Breach Report.
 
 In addition to the millions of dollars lost due to breaches the report finds that the **mean time to identify** a breach continues to hover around **200 days**. Clearly our ability to monitor applications and alert on anomalous behavior would improve our time to identify and mitigate an attack against our applications.
 
@@ -622,7 +622,7 @@ WARN
 **Description**
 When attempts are made from unauthorized origins they should of course be blocked, but also logged whenever possible. Even if we block an illegal cross-origin request the fact that the request is being made could be an indication of attack.
 
-*NOTE: Did you know that the word "referer" is mispelled in the original HTTP specification? The correct spelling should be "referrer" but the original typo persists to this day and is used here intentionally.*
+*NOTE: Did you know that the word "referer" is misspelled in the original HTTP specification? The correct spelling should be "referrer" but the original typo persists to this day and is used here intentionally.*
 
 **Level:**
 WARN
@@ -635,7 +635,7 @@ WARN
     "appid": "foobar.netportal_auth",
     "event": "malicious_cors:127.0.0.1,Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0,attack.evil.com",
     "level": "WARN",
-    "description": "An illegal cross-origin request from 127.0.0.1 was refered from attack.evil.com"
+    "description": "An illegal cross-origin request from 127.0.0.1 was referred from attack.evil.com"
     ...
 }
 ```

cheatsheets/Error_Handling_Cheat_Sheet.md

@@ -405,4 +405,4 @@ The source code of all the sandbox projects created to find the right setup to u
 
 ## Appendix HTTP Errors
 
-A reference for HTTP errors can be found here [RFC 2616](https://www.ietf.org/rfc/rfc2616.txt). Using error messages that do not provide implementation details is important to avoid information leakage. In general, consider using 4xx error codes for requests that are due to an error on the part of the HTTP client (e.g. unauthorized access, request body too large) and use 5xx to indicate errors that are triggered on server side, due to an unforseen bug. Ensure that applications are monitored for 5xx errors which are a good indication of the application failing for some sets of inputs.
+A reference for HTTP errors can be found here [RFC 2616](https://www.ietf.org/rfc/rfc2616.txt). Using error messages that do not provide implementation details is important to avoid information leakage. In general, consider using 4xx error codes for requests that are due to an error on the part of the HTTP client (e.g. unauthorized access, request body too large) and use 5xx to indicate errors that are triggered on server side, due to an unforeseen bug. Ensure that applications are monitored for 5xx errors which are a good indication of the application failing for some sets of inputs.

cheatsheets/File_Upload_Cheat_Sheet.md

@@ -76,7 +76,7 @@ _The Content-Type for uploaded files is provided by the user, and as such cannot
 
 Other than defining the extension of the uploaded file, its MIME-type can be checked for a quick protection against simple file upload attacks.
 
-This can be done preferrably in an allow list approach; otherwise, this can be done in a block list approach.
+This can be done preferably in an allow list approach; otherwise, this can be done in a block list approach.
 
 ### File Signature Validation
 

cheatsheets/Forgot_Password_Cheat_Sheet.md

@@ -119,4 +119,4 @@ Security questions should not be used as the sole mechanism for resetting passwo
 
 ## Account Lockout
 
-Accounts should not be locked out in response to a forgotten password attack, as this can be used to deny access to users with known usernames. For more details on account lockouts, see the [Authenication Cheat Sheet](Authentication_Cheat_Sheet.md).
+Accounts should not be locked out in response to a forgotten password attack, as this can be used to deny access to users with known usernames. For more details on account lockouts, see the [Authentication Cheat Sheet](Authentication_Cheat_Sheet.md).

cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.md

@@ -213,7 +213,7 @@ Code using it to perform XPath query.
 /*Create a XML document builder factory*/
 DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
 
-/*Disable External Entity resolution for differents cases*/
+/*Disable External Entity resolution for different cases*/
 //Do not performed here in order to focus on variable resolver code
 //but do it for production code !
 

cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.md

@@ -125,7 +125,7 @@ public Map<String, String> listAllMovies() {
     try {
         this.movies.forEach(m -> {
             try {
-                //Compute the front end ID fof the current element
+                //Compute the front end ID for the current element
                 String frontEndId = IDORUtil.computeFrontEndIdentifier(m.getBackendIdentifier());
                 //Add the computed ID and the associated item name to the result map
                 result.put(frontEndId, m.getName());

cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.md

@@ -91,7 +91,7 @@ private transient byte[] keyHMAC = ...;
 //explicitly the use of the HMAC-256 hashing algorithm
 JWTVerifier verifier = JWT.require(Algorithm.HMAC256(keyHMAC)).build();
 
-//Verify the token, if the verification fail then a exception is throwed
+//Verify the token, if the verification fail then a exception is thrown
 DecodedJWT decodedToken = verifier.verify(token);
 ```
 
@@ -108,7 +108,7 @@ A way to prevent it is to add a "user context" in the token. A user context will
 - A random string that will be generated during the authentication phase. It will be sent to the client as an hardened cookie (flags: [HttpOnly + Secure](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies) + [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies) + [cookie prefixes](https://googlechrome.github.io/samples/cookie-prefixes/)).
 - A SHA256 hash of the random string will be stored in the token (instead of the raw value) in order to prevent any XSS issues allowing the attacker to read the random string value and setting the expected cookie.
 
-IP addresses should not be used because there are some legitimate situations in which the IP address can change during the same session. For example, when an user accesses an application through their mobile device and the mobile operator changes during the exchange, then the IP address may (often) change. Moreover, using the IP address can potentially cause issues with [European GDPR](http://www.eugdpr.org/) compliancy.
+IP addresses should not be used because there are some legitimate situations in which the IP address can change during the same session. For example, when an user accesses an application through their mobile device and the mobile operator changes during the exchange, then the IP address may (often) change. Moreover, using the IP address can potentially cause issues with [European GDPR](http://www.eugdpr.org/) compliance.
 
 During token validation, if the received token does not contain the right context (for example, if it has been replayed), then it must be rejected.
 

cheatsheets/Kubernetes_Security_Cheat_Sheet.md

@@ -169,7 +169,7 @@ To prevent attacks via the dashboard, you should follow some tips:
 - Grant permissions per user, so each user only can see what they are supposed to see
 - If you are using network policies, you can block requests to the dashboard even from internal pods (this will not affect the proxy tunnel via kubectl proxy)
 - Before version 1.8, the dashboard had a service account with full privileges, so check that there is no role binding for cluster-admin left.
-- Deploy the dashboard with an authenticating reverse proxy, with multi-factor authentication enabled.  This can be done with either embeded OIDC `id_tokens` or using Kubernetes Impersonation.  This allows you to use the dashboard with the user's credentials instead of using a privileged `ServiceAccount`.  This method can be used on both on-prem and managed cloud clusters.
+- Deploy the dashboard with an authenticating reverse proxy, with multi-factor authentication enabled.  This can be done with either embedded OIDC `id_tokens` or using Kubernetes Impersonation.  This allows you to use the dashboard with the user's credentials instead of using a privileged `ServiceAccount`.  This method can be used on both on-prem and managed cloud clusters.
 
 ## Kubernetes Security Best Practices: Build Phase
 
@@ -205,7 +205,7 @@ For more information on ditroless images, refer to <https://github.com/GoogleCon
 
 #### Scratch image
 
-An empty image, ideal for statically compiled languages like Go. Because the image is empty - the attack surface it truely minimal - only your code!
+An empty image, ideal for statically compiled languages like Go. Because the image is empty - the attack surface it truly minimal - only your code!
 
 For more information, refer to <https://hub.docker.com/_/scratch>
 

cheatsheets/Logging_Cheat_Sheet.md

@@ -15,7 +15,7 @@ Application logging should be always be included for security events. Applicatio
 - Identifying security incidents
 - Monitoring policy violations
 - Establishing baselines
-- Assisting non-repudiation controls (note that the trait non-repudiation is hard to achieve for logs because their trustworthyness is often just based on the logging party being audited properly while machanisms like digital signatures are hard to utilize here)
+- Assisting non-repudiation controls (note that the trait non-repudiation is hard to achieve for logs because their trustworthiness is often just based on the logging party being audited properly while mechanisms like digital signatures are hard to utilize here)
 - Providing information about problems and unusual conditions
 - Contributing additional application-specific data for incident investigation which is lacking in other log sources
 - Helping defend against vulnerability identification and exploitation through attack detection
@@ -196,7 +196,7 @@ In some systems, sanitization can be undertaken post log collection, and prior t
 It may be desirable to be able to alter the level of logging (type of events based on severity or threat level, amount of detail recorded). If this is implemented, ensure that:
 
 - The default level must provide sufficient detail for business needs
-- It should not be possible to completely inactivate application logging or logging of events that are necessary for compliance requirements
+- It should not be possible to completely deactivate application logging or logging of events that are necessary for compliance requirements
 - Alterations to the level/extent of logging must be intrinsic to the application (e.g. undertaken automatically by the application based on an approved algorithm) or follow change management processes (e.g. changes to configuration data, modification of source code)
 - The logging level must be verified periodically
 

cheatsheets/Microservices_security.md

@@ -68,7 +68,7 @@ Netfix presented ([link](https://www.youtube.com/watch?v=R6tUNpRpdnY), [link](ht
     - gateways and proxies level at a coarse level of granularity;
     - microservice level using shared authorization library/components to enforce fine-granted decisions;
     - microservice business code level to implement business-specific access control rules.
-6. Access control policy formal procedures like development, approvement, rolling-out must be implemented.
+6. Access control policy formal procedures like development, approval, rolling-out must be implemented.
 
 ## External entity identity propagation
 
@@ -80,12 +80,12 @@ To make fine-granted authorization decision at the microservice level microservi
 
 In that approach calling microservice extracts external entity identity from incoming request (e.g. via parsing incoming access token), creates data structure (e.g. JSON or self-signed JWT) with context and passes that on to an internal microservices.
 In this scenario recipient microservice has to trust the calling microservice -- if the calling microservice want to violate access control rules, it can do so by setting any user/client ID or user roles it wants as the HTTP header. That approach is applicable in a highly trusted environment in which every microservice is developed by trusted development team according with secure software development practices.
-![Clear text ID propogation](../assets/ID_propogation.png)
+![Clear text ID propagation](../assets/ID_propogation.png)
 
 #### Using a data structures signed by a trusted issuer
 
 In this pattern after the external request is authenticated by authentication service at the edge layer, a data structure representing external entity identity (e.g., contained user ID, user roles/groups or permissions) is generated, signed or encrypted by the trusted issuer and propagated  to internal microservices.
-![Signed ID propogation](../assets/Signed_ID_propogation.png)
+![Signed ID propagation](../assets/Signed_ID_propogation.png)
 
 [Netflix presented](https://www.infoq.com/presentations/netflix-user-identity/) a real case of using that pattern: structure called “Passport” that contains user ID and its attributes and HMAC protected is created at the edge level for each incoming request, propagated to internal microservices and never exposes outside:
 
@@ -95,10 +95,10 @@ In this pattern after the external request is authenticated by authentication se
 4. Internal services can extract user identity in order to enforce authorization (e.g. to implement identity-based authorization) using wrappers.
 5. If necessary, internal service can propagate “Passport” structure to downstream services in the call chain.
 
-![Netflix ID propogation approach](../assets/Netflix_ID_prop.png)
+![Netflix ID propagation approach](../assets/Netflix_ID_prop.png)
 It should be mentioned that pattern is external access token agnostic and allows to decouple external entity and its internal representation.
 
-### Recommendation on how to implement identity propogation
+### Recommendation on how to implement identity propagation
 
 1. In order to implement external access token agnostic and extendable system decouple access tokens issued for external entity from its internal representation. Use single data structure to represent and propagate external entity identity among microservices. Edge-level service has to verify incoming external access token, issue internal entity representation structure and propagate it to downstream services.
 2. Using an internal entity representation structure signed (symmetric or asymmetric encryption) by a trusted issuer is recommended pattern adopted by community.
@@ -116,7 +116,7 @@ In mTLS approach each microservice can legitimately identify who it talks to, in
 #### Token based
 
 Token based approach works at the application layer. Token is a container and may contain caller ID (microservice ID) and its permissions (scopes). Caller microservice can obtain signed token by invoking special security token service using its own service ID and password and then attaches it to every outgoing requests e.g., via HTTP headers. Called microservice can extract token and validate it online or offline.
-![Signed ID propogation](../assets/Token_validation.png)
+![Signed ID propagation](../assets/Token_validation.png)
 
 1. Online scenario:
     - to validate incoming token microservice invokes centralized service token service via network call;

cheatsheets/Password_Storage_Cheat_Sheet.md

@@ -4,7 +4,7 @@
 
 It is essential to store passwords in a way that prevents them from being obtained by an attacker even if the application or database is compromised. The majority of modern languages and frameworks provide built-in functionality to help store passwords safely.
 
-After an attacker has aquired stored password hashes, they are always able to brute force hashes offline. As a defender, it is only possible to slow down offline attacks by selecting hash algorithms that are as resource intensive as possible.
+After an attacker has acquired stored password hashes, they are always able to brute force hashes offline. As a defender, it is only possible to slow down offline attacks by selecting hash algorithms that are as resource intensive as possible.
 
 This cheat sheet provides guidance on the various areas that need to be considered related to storing passwords. In short:
 

cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.md

@@ -304,7 +304,7 @@ The first validation on the input data presented in the case [n°1](Server_Side_
 4. The application will receive the parameter name for the token to pass to the *TargetedApplication* via a dedicated input parameter for which it will only allow the characters set `[a-z]{1,10}`.
 5. The application will receive the token itself via a dedicated input parameter for which it will only allow the characters set `[a-zA-Z0-9]{20}`.
 6. The application will receive and validate (from a security point of view) any business data needed to perform a valid call.
-7. The application will build the HTTP POST request **using only validated informations** and will send it (*don't forget to disable the support for [redirection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections) in the web client used*).
+7. The application will build the HTTP POST request **using only validated information** and will send it (*don't forget to disable the support for [redirection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections) in the web client used*).
 
 **Hints for the step 2 regarding the verification on an IP address:**