Fix a couple of typos, an incomplete sentence, and some invalid code (#58)

Author: BrentWheeldon

modules/2-owasp.livemd

@@ -291,7 +291,7 @@ Notable CWEs included are CWE-297: Improper Validation of Certificate with Host
 * Limit or increasingly delay failed login attempts.
   * Log all failures and alert the Security team when credential stuffing, brute force, or other attacks are detected.
 * Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login.
-  * Session identifier should not be in the URL, be securely stored, and invalidated after logout, idle,
+  * Session identifier should not be in the URL, be securely stored, and invalidated after logout, idle, and absolute timeouts.
 
 <!-- livebook:{"branch_parent_index":3} -->
 
@@ -345,7 +345,7 @@ Notable CWES include CWE-778 Insufficient Logging to include CWE-117 Improper Ou
 
 Server-Side Request Forgery (SSRF) flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).
 
-This is determental since these flaws could be leveraged as part of a botnet or even to further exploit other services in your network that are only accessible in a Service-to-Service context (e.g. not available to public internet, but only to services in the same VPC).
+This is detrimental since these flaws could be leveraged as part of a botnet or even to further exploit other services in your network that are only accessible in a Service-to-Service context (e.g. not available to public internet, but only to services in the same VPC).
 
 ### Prevention
 

modules/4-graphql.livemd

@@ -92,7 +92,7 @@ _Uncomment the item number (1-4) with your answer_
 
 ```elixir
 # -------------------------------------------------------------
-# answer = :1
+# answer = 1
 #
 # HTTP/2 401 Unauthorized
 # Date: Tues, 16 Aug 2022 21:06:42 GMT
@@ -101,7 +101,7 @@ _Uncomment the item number (1-4) with your answer_
 # 	“error”:”token expired”
 # {
 # -------------------------------------------------------------
-# answer = :2
+# answer = 2
 #
 # HTTP/2 200 OK
 # Date: Tues, 16 Aug 2021 22:06:42 GMT
@@ -120,7 +120,7 @@ _Uncomment the item number (1-4) with your answer_
 # 	]
 # }
 # --------------------------------------------------------------
-# answer = :3
+# answer = 3
 #
 # HTTP/2 200 OK
 # Date: Tues, 16 Aug 2022 21:06:42 GMT
@@ -129,7 +129,7 @@ _Uncomment the item number (1-4) with your answer_
 # 	“error”:”ID token for user 55e4cb07 at org 1234 expired”
 # {
 # ---------------------------------------------------------------
-# answer = :4
+# answer = 4
 #
 # HTTP/2 404 File Not Found
 # Date: Tues, 16 Aug 2022 21:06:42 GMT

modules/9-secure-road.livemd

@@ -35,7 +35,7 @@ With all that in mind, in this final module let's explore some examples of Data
 
 In a microservice architecture, it is common for backend services to need to communicate with one another - sometimes that could be a call and response interaction other times a "fire and forget" interaction. Regardless of how they interface with one another, there still remains a need for the receipent of the interaction to verify the communication is coming from a trusted source.
 
-In its most basic form, you can have this authentication paradigm look like a Service to Service Token - where the reciepent looks for a securely generated code provided as data along with the request.
+In its most basic form, you can have this authentication paradigm look like a Service to Service Token - where the recipient looks for a securely generated code provided as data along with the request.
 
 Now let's say in our scenario, the receiving service is being communicated with by multiple senders (meaning more than one other service is writing to its API). Would it be better to: