spelling fixes

OWASP · Sep 10, 2024 · 4537d2b · 4537d2b
1 parent 22bde74
commit 4537d2b
Show file tree

Hide file tree

Showing 14 changed files with 58 additions and 31 deletions.
diff --git a/.wordlist.txt b/.wordlist.txt
@@ -11,13 +11,17 @@ APIs
 AppSec
 Aref
 ASVS
+authenticator
 autobinding
 backend
 Baillon
+bcrypt
 Braiterman
 BSIMM
 caniuse
 Caniuse
+canonicalization
+Canonicalization
 Capellan
 Cassio
 cd
@@ -26,23 +30,28 @@ cheatsheetseries
 Checkov
 Chih
 Chorzevski
+CIS
 CLI
 clickjacking
 Clickjacking
 Cloudmapper
 Coiro
+ColdFusion
 config
 CORS
 Coursera
 crypto
 cryptographic
+cryptographically
 CSP
 CSRF
 CSRF
 CVE
 CWE
+Cx
 Cybuck
 Cyrille
+DAC
 danielmiessler
 Datz
 de
@@ -61,6 +70,7 @@ DevSlop
 DNS
 docx
 DOM
+DOMPurify
 Dracea
 DSS
 DTOs
@@ -95,6 +105,7 @@ HTTPS
 IaC
 ideation
 IDOR
+iframes
 intransparency
 io
 ISC
@@ -103,6 +114,7 @@ Ivashchenko
 Jasmin
 JavaScript
 JEA
+JEP
 JIT
 Joubert
 JS
@@ -111,13 +123,18 @@ JSR
 JWS
 JWT
 JWTs
+keychain
+keystore
+KeyWhiz
 KICS
 KMS
 Koichiro
 Kubernetes
 Kubescape
 Kuramochi
 Kyverno
+LDAP
+Libsodium
 linkedin
 localhost
 Mair
@@ -126,19 +143,23 @@ Massimiliano
 MASVS
 Microservices
 Miessler
+Misconfiguration
 misconfigure
 mkdocs
 Mohammed
 Nagai
 NCSC
 NIST
 nonces
+NoSQL
 NVD
 OAuth
 OKADA
 oneconsult's
+OPC
 OpenSAMM
 OpenSSF
+OQL
 ORM
 Osama
 OTP
@@ -156,6 +177,7 @@ programmatically
 py
 RBAC
 RCE
+reactively
 realtime
 ReDoS
 Referer
@@ -167,11 +189,13 @@ Saft
 SameSite
 SAMM
 sandbopxing
+sandboxing
 Sanitization
 SAST
 SBOM
 SBOMs
 SCA
+scalability
 SecLists
 securitypatterns
 Shaheed
@@ -200,6 +224,7 @@ Tfsec
 ThreeHoolagins
 ThunderSon
 Timo
+Tink
 TLS
 TLSv
 Transformative
@@ -212,6 +237,7 @@ untrusted
 Validator
 Vanhilst
 venv
+verifier
 Vries
 Watanabe
 WebAuthn
@@ -221,4 +247,5 @@ www
 XEE
 XFO
 XSS
+Zend
 Zudilin
diff --git a/docs/archive/2018/c3-secure-database.md b/docs/archive/2018/c3-secure-database.md
@@ -13,13 +13,13 @@ This section describes secure access to all data stores, including both relation
 
 SQL Injection occurs when untrusted user input is dynamically added to a SQL query in an insecure manner, often via basic string concatenation. SQL Injection is one of the most dangerous application security risks. SQL Injection is easy to exploit and could lead to the entire database being stolen, wiped, or modified. The application can even be used to run dangerous commands against the operating system hosting your database, thereby giving an attacker a foothold on your network.
 
-In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as 'Query Parameterization'. This defense should be applied to SQL, OQL, as well as stored procedure construction.
+In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as 'Query Parametrization'. This defense should be applied to SQL, OQL, as well as stored procedure construction.
 
-A good list of query parameterization examples in ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at [http://bobby-tables.com](http://bobby-tables.com/) and the [OWASP Cheat Sheet on Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html).
+A good list of query parameterization examples in ASP, ColdFusion, C#, Delphi, .NET, Go, Java, Perl, PHP, PL/SQL, PostgreSQL, Python, R, Ruby and Scheme can be found at [http://bobby-tables.com](http://bobby-tables.com/) and the [OWASP Cheat Sheet on Query Parametrization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html).
 
-#### Caution on Query Parameterization
+#### Caution on Query Parametrization
 
-Certain locations in a database query are not parameterizable. These locations are different for each database vendor. Be certain to do very careful exact-match validation or manual escaping when confronting database query parameters that cannot be bound to a parameterized query. Also, while the use of parameterized queries largely has a positive impact on performance, certain parameterized queries in specific database implementations will affect performance negatively. Be sure to test queries for performance; especially complex queries with extensive like clause or text searching capabilities.
+Certain locations in a database query can not be used with parametrization. These locations are different for each database vendor. Be certain to do very careful exact-match validation or manual escaping when confronting database query parameters that cannot be bound to a parameterized query. Also, while the use of parameterized queries largely has a positive impact on performance, certain parameterized queries in specific database implementations will affect performance negatively. Be sure to test queries for performance; especially complex queries with extensive like clause or text searching capabilities.
 
 ### Secure Configuration
 
@@ -46,7 +46,7 @@ A quick guidance on providing a secure communication mean can be found in the [D
 
 ## References
 
-* [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html)
+* [OWASP Cheat Sheet: Query Parametrization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html)
 * [OWASP Cheat Sheet: Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html)
 * [Bobby Tables: A guide to preventing SQL injection](http://bobby-tables.com/)
 * [CIS Database Hardening Standards](https://www.cisecurity.org/cis-benchmarks/)
diff --git a/docs/archive/2018/c5-validate-inputs.md b/docs/archive/2018/c5-validate-inputs.md
@@ -8,7 +8,7 @@ Input validation is a programming technique that ensures only properly formatted
 
 An application should check that data is both *syntactically* and *semantically* valid (in that order) before using it in any way (including displaying it back to the user).
 
-**Syntax validity** means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit "account ID" to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parameterization).
+**Syntax validity** means that the data is in the form that is expected. For example, an application may allow a user to select a four-digit "account ID" to perform some kind of operation. The application should assume the user is entering a SQL injection payload, and should check that the data entered by the user is exactly four digits in length, and consists only of numbers (in addition to utilizing proper query parametrization).
 
 **Semantic validity** includes only accepting input that is within an acceptable range for the given application functionality and context. For example, a start date must be before an end date when choosing date ranges.
 
@@ -46,7 +46,7 @@ Regular expressions are just one way to accomplish validation. Regular expressio
 
 ### Limits of Input Validation
 
-**Input validation does not always make data "safe" since certain forms of complex input may be "valid" but still dangerous. For example, a valid email address may contain a SQL injection attack or a valid URL may contain a Cross Site Scripting attack**. Additional defenses besides input validation should always be applied to data such as query parameterization or escaping.
+**Input validation does not always make data "safe" since certain forms of complex input may be "valid" but still dangerous. For example, a valid email address may contain a SQL injection attack or a valid URL may contain a Cross Site Scripting attack**. Additional defenses besides input validation should always be applied to data such as query parametrization or escaping.
 
 ### Challenges of Validating Serialized Data
 

diff --git a/docs/archive/2018/c6-digital-identity.md b/docs/archive/2018/c6-digital-identity.md
@@ -96,7 +96,7 @@ Server-side sessions can be limiting for some forms of authentication. "Stateles
 
 JSON Web Token (JWT) is an open standard ([RFC 7519](https://tools.ietf.org/html/rfc7519)) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. A JWT token is created during authentication and is verified by the server (or servers) before any processing.
 
-However, JWT's are often not saved by the server after initial creation. JWT's are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation.
+However, JWTs are often not saved by the server after initial creation. JWT's are typically created and then handed to a client without being saved by the server in any way. The integrity of the token is maintained through the use of digital signatures so a server can later verify that the JWT is still valid and was not tampered with since its creation.
 
 This approach is both stateless and portable in the way that client and server technologies can be different yet still interact.
 

diff --git a/docs/archive/2018/c8-protect-data-everywhere.md b/docs/archive/2018/c8-protect-data-everywhere.md
@@ -8,11 +8,11 @@ Attackers can steal data from web and webservice applications in a number of way
 
 ## Data Classification
 
-It's critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is ok to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit.
+It's critical to classify data in your system and determine which level of sensitivity each piece of data belongs to. Each data category can then be mapped to protection rules necessary for each level of sensitivity. For example, public marketing information that is not sensitive may be categorized as public data which is okay to place on the public website. Credit card numbers may be classified as private user data which may need to be encrypted while stored or in transit.
 
 ## Encrypting Data in Transit
 
-When transmitting sensitive data over any network, end-to-end communications security (or encryption-in-transit) of some kind should be considered. TLS is by far the most common and widely supported cryptographic protocol for communications security. It is used by many types of applications (web, webservice, mobile) to communicate over a network in a secure fashion. TLS must be properly configured in a variety of ways in order to properly defend secure communications.
+When transmitting sensitive data over any network, end-to-end communications security (or encryption-in-transit) of some kind should be considered. TLS is by far the most common and widely supported cryptographic protocol for communications security. It is used by many types of applications (web, web service, mobile) to communicate over a network in a secure fashion. TLS must be properly configured in a variety of ways in order to properly defend secure communications.
 
 The primary benefit of transport layer security is the protection of web application data from unauthorized disclosure and modification when it is transmitted between clients (web browsers) and the web application server, and between the web application server and back end and other non-browser based enterprise components.
 
@@ -46,7 +46,7 @@ When an immutable datatype such as `string` is used to store secrets, secrets ca
 Even if you try to nullify the string value, it still remains in the memory.
 `string` is an immutable type and cannot be changed. When you modify a string (try to overwrite it), a new copy of it is created.
 This means another copy of the unprotected secret will remain in the memory.
-Furthermore, there is no gurantee when garbage collector is going to clean up the secret.
+Furthermore, there is no guarantee when garbage collector is going to clean up the secret.
 This increases exposure of plaintext secrets in the memory.
 
 If secrets remain unprotected in the memory, they can get disclosed on the disk or external log aggregators
@@ -60,7 +60,7 @@ For an example implementation see [this post](https://discuss.secdim.com/t/do-no
 
 Applications contain numerous "secrets" that are needed for security operations. These include certificates, SQL connection passwords, third party service account credentials, passwords, SSH keys, encryption keys and more. The unauthorized disclosure or modification of these secrets could lead to complete system compromise. In managing application secrets, consider the following.
 
-* Don't store secrets in code, config files or pass them through environment variables. Use tools like [GitRob](https://github.com/michenriksen/gitrob) or [TruffleHog](https://github.com/dxa4481/truffleHog) to scan code repos for secrets.
+* Don't store secrets in code, config files or pass them through environment variables. Use tools like [GitRob](https://github.com/michenriksen/gitrob) or [TruffleHog](https://github.com/dxa4481/truffleHog) to scan code repositories for secrets.
 * Keep keys and your other application-level secrets in a secrets vault like [KeyWhiz](https://github.com/square/keywhiz) or [Hashicorp's Vault project](https://www.vaultproject.io/) or [Amazon KMS](https://aws.amazon.com/kms/) to provide secure storage and access to application-level secrets at run-time.
 
 ## Vulnerabilities Prevented

diff --git a/docs/introduction/related-owasp-projects.md b/docs/introduction/related-owasp-projects.md
@@ -12,11 +12,11 @@ The best-known OWASP document is the [OWASP Top 10](https://owasp.org/Top10/). T
 
 ## OWASP SAMM
 
-[Software Assurance Maturity Model (SAMM)](https://www.opensamm.org/) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . [SAMM](https://owaspsamm.org/about/) supports the complete software lifecycle and can be used to identify what
+[Software Assurance Maturity Model (SAMM)](https://www.opensamm.org/) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . [SAMM](https://owaspsamm.org/about/) supports the complete software life cycle and can be used to identify what
 
 ## Threat Modeling in General
 
-Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) can be used to create threat model diagrams as part of a secure development lifecycle.
+Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) can be used to create threat model diagrams as part of a secure development life cycle.
 
 ## Domain-Specific Documents
 

diff --git a/docs/the-top-10/c1-accesscontrol.md b/docs/the-top-10/c1-accesscontrol.md
@@ -53,7 +53,7 @@ An example of implementing that principle is to create dedicated privileged role
 
 To further improve the security, you can implement Just-in-Time (JIT) or Just-enough-Access (JEA): ensure that all users, programs, or processes are only given just enough access to achieve their current mission. This access should be provided just in time, when the subject makes the request, and the access should be granted for a short time. Be wary of systems that do not provide granular access control configuration capabilities.
 
-### 6) Do not Hardcode Roles
+### 6) Do not Hard-code Roles
 
 Many application frameworks default to access control that is role based. It is common to find application code filled with checks of this nature.