slowly getting there with the spelling fixes

.wordlist.txt

@@ -5,6 +5,7 @@ Adriaan
 AES
 Andreas
 APIs
+AppSec
 Aref
 ASVS
 Baillon
@@ -37,6 +38,13 @@ Datz
 de
 decrypt
 Der
+deserialization
+deserialize
+deserializes
+DevOps
+DevOpsSec
+DevSecOps
+DevSlop
 docx
 DOM
 Dracea
@@ -55,6 +63,7 @@ Goldschmidt
 Grandval
 Graziani
 Grossman
+HackerCombat
 Happe
 Hashicorp
 Heyes
@@ -64,15 +73,19 @@ Hiroshi
 Hsiang
 HSTS
 Hsu
+httpOnly
 HTTPS
 IaC
+IDOR
+ISC
 Ishaq
 Ivashchenko
 Jasmin
 JEA
 JIT
 Joubert
 JSON
+JSR
 JWS
 JWT
 JWTs
@@ -94,9 +107,11 @@ Nagai
 NIST
 nonces
 OKADA
+oneconsult's
 OpenSAMM
 Osama
 OTP
+owasp
 OWASP
 Pagel
 PassKeys
@@ -110,6 +125,7 @@ Riotaro
 RNG
 SameSite
 SAMM
+Sanitization
 SAST
 SBOM
 SBOMs
@@ -128,6 +144,8 @@ SSRF
 SSRFMap
 SSTI
 Taras
+TechBeacon
+Teil
 Temmar
 Terraform
 Terrascan
@@ -137,10 +155,13 @@ ThreeHoolagins
 ThunderSon
 Timo
 TLS
+Transformative
 Trivy
 TruffleHog
 UCDavies
 UI
+untrusted
+Validator
 venv
 Vries
 Watanabe

docs/final-word.md

@@ -6,5 +6,5 @@ Good next steps to help build an application security program include:
 
 1. To understand some of the risks in web application security please review the [OWASP Top Ten](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) .
 2. A secure development program should include a *comprehensive list of security requirements* .
- Use [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) to identify potential security threats, derive security requirements, and tailor security controls to prevent those. Use standards such as the [OWASP (Web) ASVS](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) and the [OWASP (Mobile) MASVS](https://github.com/OWASP/owasp-masvs) which provides a catalog of available security requirements along wiht the  relevant verification criteria.
+ Use [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) to identify potential security threats, derive security requirements, and tailor security controls to prevent those. Use standards such as the [OWASP (Web) ASVS](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) and the [OWASP (Mobile) MASVS](https://github.com/OWASP/owasp-masvs) which provides a catalog of available security requirements along with the  relevant verification criteria.
 3. To understand the core building blocks of a secure software program from a more macro point of view please review the [OWASP OpenSAMM project](https://www.owasp.org/index.php/OWASP_SAMM_Project).

docs/the-top-10/c4-secure-architecture.md

@@ -2,7 +2,7 @@
 
 ## Description
 
-When designing a new application, creating a secure architecture prevents vulnerabilties before they even become part of the application. This prevents costly repairs and repudiation problems.
+When designing a new application, creating a secure architecture prevents vulnerabilities before they even become part of the application. This prevents costly repairs and repudiation problems.
 
 There are design principles that lead to secure architectures:
 
@@ -14,7 +14,7 @@ There are design principles that lead to secure architectures:
 
 ## Threats
 
-- If the application is only protected by security-by-obscurity, an attacker that reverse-engineers the application has full permissions as soon the obfuscation is cleared-up. In addtion, an attacker is able to monitor network traffic: while the obfuscation might be performed on the code-level, the operations on the network level can easily be analyzed.
+- If the application is only protected by security-by-obscurity, an attacker that reverse-engineers the application has full permissions as soon the obfuscation is cleared-up. In addition, an attacker is able to monitor network traffic: while the obfuscation might be performed on the code-level, the operations on the network level can easily be analyzed.
 - A web-application with a complex authorization scheme is deployed. A new software developer is tasked with extending one of the components. Due to the complexity, they misconfigure the authorization scheme and an attacker is able to exploit IDOR.
 - A web-application with a complex authorization scheme is deployed. A new software developer adds a new plugin to the system. The system makes it hard to do the right thing, and all security configuration must be manually added to the plugin, by-default no security measures are taken. The new developer is not configuring anything thus the new plugin introduces an IDOR into the system.
 - A web-application has many components, all of which are exposed to the public internet. The resulting attack surface is massive. For example, a database management tool (e.g., `phpmyadmin`) is deployed. After a 0day was found in `mysqladmin`, the whole database was extracted. During normal use, nobody uses `phpmyadmin`.