provide identifiers to the checklist

Author: jgadsden

_data/draft.yaml

@@ -4,7 +4,7 @@ docs:
 - title: '1. Introduction'
   url: introduction
 
-- title: '*2. Foundations*'
+- title: '2. Foundations'
   url: foundations
 
 - title: '2.1 Security fundamentals'

draft/06-design/01-threat-modeling/04-cornucopia.md

@@ -32,26 +32,25 @@ during the software development life cycle.
 
 #### What is Cornucopia?
 
-Cornucopia provides a [set of cards][cornucopia-cards] designed to gamify threat modeling activities.
-This is designed so that agile development teams can identify weaknesses in web applications
-and then record remediations or requirements.
+Cornucopia provides a [set of cards][cornucopia-cards] designed to gamify threat modeling activities,
+helping agile development teams to identify weaknesses in applications and then record remediations or requirements.
 
 There are three versions of the Cornucopia deck of threat modeling cards:
 
 * Website App Edition
 * Mobile App Edition
 * Enterprise App Edition
 
-The decks come with different suits according to the application, and always contain a 'Cornucopia' suit.
+The decks come with several suits according to the application, and always contain an overall 'Cornucopia' suit.
 
-There is no one 'right' way to play Cornucopia but there is a suggested [set of rules][cornucopia-play]
-to start the game off.
-Cornucopia provides a [score sheet][cornucopia-score] to help keep track of the game session and to record outcomes.
+Cornucopia can be played in many different ways, there is no one way,
+and there is a suggested [set of rules][cornucopia-play] to start the game off.
+Cornucopia provides a [score sheet][cornucopia-score] to can help keep track of the game session and to record outcomes.
 
 #### Website App Edition
 
 Each card in the Website App deck describes a common error or anti-pattern that allows systems to be vulnerable to attack.
-Vulnerabilities are arranged in domains as five key suits, with the additional Cornucopia suit ranging across domains:
+Vulnerabilities are arranged in domains as five suits with the additional Cornucopia suit ranging across these domains:
 
 * Data Validation and Encoding
 * Authentication
@@ -82,7 +81,7 @@ with Cornucopia cross domain:
 * Cryptography
 * Cornucopia
 
-To provide context the Cornucopia Mobile App cards reference other projects:
+For context the Cornucopia Mobile App cards reference these other projects:
 
 * OWASP Mobile Application Security Verification Standard ([MASVS][masvs])
 * OWASP Mobile Application Security Testing Guide ([MASTG][mastg])
@@ -92,7 +91,8 @@ To provide context the Cornucopia Mobile App cards reference other projects:
 #### Ecommerce Website Edition
 
 This is the original Cornucopia deck and has the same domains/suits, including the Cornucopia cross domain suit,
-as the Website App Edition. Some of the vulnerabilities are specific to Ecommerce, and it references the same projects.
+as the Website App Edition. Some of the vulnerabilities are specific to Ecommerce,
+but it references the same projects as the website edition.
 
 #### Why use it?
 

draft/06-design/02-web-app-checklist/01-define-security-requirements.md

@@ -21,46 +21,46 @@ Refer to proactive control [C1: Define Security Requirements][control1]
 for more context from the OWASP Top 10 Proactive Controls project,
 and use the lists below as suggestions for a checklist that has been tailored for the individual project.
 
-#### System configuration
-
-* Restrict applications, processes and service accounts to the least privileges possible
-* If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible
-* Remove all unnecessary functionality and files
-* Remove test code or any functionality not intended for production, prior to deployment
-* The security configuration store for the application should be available in human readable form to support auditing
-* Isolate development environments from production and provide access only to authorized development and test groups
-* Implement a software change control system to manage and record changes to the code both in development and production
-
-#### Cryptographic practices
-
-* Use peer reviewed and open solution cryptographic modules
-* All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system
-* Cryptographic modules must fail securely
-* Ensure all random elements such as numbers, file names, UUID and strings are generated
+#### 1. System configuration
+
+1. Restrict applications, processes and service accounts to the least privileges possible
+1. If the application must run with elevated privileges, raise privileges as late as possible, and drop as soon as possible
+1. Remove all unnecessary functionality and files
+1. Remove test code or any functionality not intended for production, prior to deployment
+1. The security configuration store for the application should be available in human readable form to support auditing
+1. Isolate development environments from production and provide access only to authorized development and test groups
+1. Implement a software change control system to manage and record changes to the code both in development and production
+
+#### 2. Cryptographic practices
+
+1. Use peer reviewed and open solution cryptographic modules
+1. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system
+1. Cryptographic modules must fail securely
+1. Ensure all random elements such as numbers, file names, UUID and strings are generated
     using the cryptographic module approved random number generator
-* Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard
-* Establish and utilize a policy and process for how cryptographic keys will be managed
-* Ensure that any secret key is protected from unauthorized access
-* Store keys in a proper secrets vault as described below
-* Use independent keys when multiple keys are required
-* Build support for changing algorithms and keys when needed
-* Build application features to handle a key rotation
-
-#### File management
-
-* Do not pass user supplied data directly to any dynamic include function
-* Require authentication before allowing a file to be uploaded
-* Limit the type of files that can be uploaded to only those types that are needed for business purposes
-* Validate uploaded files are the expected type by checking file headers rather than by file extension
-* Do not save files in the same web context as the application
-* Prevent or restrict the uploading of any file that may be interpreted by the web server.
-* Turn off execution privileges on file upload directories
-* When referencing existing files, use an allow-list of allowed file names and types
-* Do not pass user supplied data into a dynamic redirect
-* Do not pass directory or file paths, use index values mapped to pre-defined list of paths
-* Never send the absolute file path to the client
-* Ensure application files and resources are read-only
-* Scan user uploaded files for viruses and malware
+1. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard
+1. Establish and utilize a policy and process for how cryptographic keys will be managed
+1. Ensure that any secret key is protected from unauthorized access
+1. Store keys in a proper secrets vault as described below
+1. Use independent keys when multiple keys are required
+1. Build support for changing algorithms and keys when needed
+1. Build application features to handle a key rotation
+
+#### 3. File management
+
+1. Do not pass user supplied data directly to any dynamic include function
+1. Require authentication before allowing a file to be uploaded
+1. Limit the type of files that can be uploaded to only those types that are needed for business purposes
+1. Validate uploaded files are the expected type by checking file headers rather than by file extension
+1. Do not save files in the same web context as the application
+1. Prevent or restrict the uploading of any file that may be interpreted by the web server.
+1. Turn off execution privileges on file upload directories
+1. When referencing existing files, use an allow-list of allowed file names and types
+1. Do not pass user supplied data into a dynamic redirect
+1. Do not pass directory or file paths, use index values mapped to pre-defined list of paths
+1. Never send the absolute file path to the client
+1. Ensure application files and resources are read-only
+1. Scan user uploaded files for viruses and malware
 
 #### References
 

draft/06-design/02-web-app-checklist/02-frameworks-libraries.md

@@ -21,21 +21,21 @@ Refer to proactive control [C2: Leverage Security Frameworks and Libraries][cont
 for more context from the OWASP Top 10 Proactive Controls project,
 and use the list below as suggestions for a checklist that has been tailored for the individual project.
 
-#### Security Frameworks and Libraries
-
-* Ensure servers, frameworks and system components are running the latest approved versions and patches
-* Use libraries and frameworks from trusted sources that are actively maintained and widely used
-* Review all secondary applications and third party libraries to determine business necessity
-* Validate safe functionality for all secondary applications and third party libraries
-* Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA)
-* Proactively keep all third party libraries and components up to date
-* Reduce the attack surface by encapsulating the library and expose only the required behaviour into your software
-* Use tested and approved managed code rather than creating new unmanaged code for common tasks
-* Utilize task specific built-in APIs to conduct operating system tasks
-* Do not allow the application to issue commands directly to the Operating System
-* Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
-* Restrict users from generating new code or altering existing code
-* Implement safe updates using encrypted channels
+#### 1. Security Frameworks and Libraries
+
+1. Ensure servers, frameworks and system components are running the latest approved versions and patches
+1. Use libraries and frameworks from trusted sources that are actively maintained and widely used
+1. Review all secondary applications and third party libraries to determine business necessity
+1. Validate safe functionality for all secondary applications and third party libraries
+1. Create and maintain an inventory catalog of all third party libraries using Software Composition Analysis (SCA)
+1. Proactively keep all third party libraries and components up to date
+1. Reduce the attack surface by encapsulating the library and expose only the required behaviour into your software
+1. Use tested and approved managed code rather than creating new unmanaged code for common tasks
+1. Utilize task specific built-in APIs to conduct operating system tasks
+1. Do not allow the application to issue commands directly to the Operating System
+1. Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files
+1. Restrict users from generating new code or altering existing code
+1. Implement safe updates using encrypted channels
 
 #### References
 

draft/06-design/02-web-app-checklist/03-secure-database-access.md

@@ -20,31 +20,31 @@ Refer to proactive control [C3: Secure Database Access][control3]
 for more context from the OWASP Top 10 Proactive Controls project,
 and use the list below as suggestions for a checklist that has been tailored for the individual project.
 
-#### Secure queries
+#### 1. Secure queries
 
-* Use Query Parameterization to prevent untrusted input being interpreted as part of a SQL command
-* Use strongly typed parameterized queries
-* Utilize input validation and output encoding and be sure to address meta characters
-* Do not run the database command if input validation fails
-* Ensure that variables are strongly typed
-* Connection strings should not be hard coded within the application
-* Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted
+1. Use Query Parameterization to prevent untrusted input being interpreted as part of a SQL command
+1. Use strongly typed parameterized queries
+1. Utilize input validation and output encoding and be sure to address meta characters
+1. Do not run the database command if input validation fails
+1. Ensure that variables are strongly typed
+1. Connection strings should not be hard coded within the application
+1. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted
 
-#### Secure configuration
+#### 2. Secure configuration
 
-* The application should use the lowest possible level of privilege when accessing the database
-* Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database
-* Close the database connection as soon as possible
-* Turn off all unnecessary database functionality
-* Remove unnecessary default vendor content, for example sample schemas
-* Disable any default accounts that are not required to support business requirements
+1. The application should use the lowest possible level of privilege when accessing the database
+1. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database
+1. Close the database connection as soon as possible
+1. Turn off all unnecessary database functionality
+1. Remove unnecessary default vendor content, for example sample schemas
+1. Disable any default accounts that are not required to support business requirements
 
-#### Secure authentication
+#### 3. Secure authentication
 
-* Remove or change all default database administrative passwords
-* The application should connect to the database with different credentials for every trust distinction
+1. Remove or change all default database administrative passwords
+1. The application should connect to the database with different credentials for every trust distinction
     (for example user, read-only user, guest, administrators)
-* Use secure credentials for database access
+1. Use secure credentials for database access
 
 #### References
 

draft/06-design/02-web-app-checklist/04-encode-escape-data.md

@@ -25,23 +25,23 @@ Refer to proactive control [C4: Encode and Escape Data][control4]
 for more context from the OWASP Top 10 Proactive Controls project,
 and use the list below as suggestions for a checklist that has been tailored for the individual project.
 
-#### Character encoding and canonicalization
+#### 1. Character encoding and canonicalization
 
-* Apply output encoding just before the content is passed to the target system
-* Conduct all output encoding on a trusted system
-* Utilize a standard, tested routine for each type of outbound encoding
-* Specify character sets, such as UTF-8, for all outputs
-* Apply canonicalization to convert unicode data into a standard form
-* Ensure the output encoding is safe for all target systems
-* In particular sanitize all output used for operating system commands
+1. Apply output encoding just before the content is passed to the target system
+1. Conduct all output encoding on a trusted system
+1. Utilize a standard, tested routine for each type of outbound encoding
+1. Specify character sets, such as UTF-8, for all outputs
+1. Apply canonicalization to convert unicode data into a standard form
+1. Ensure the output encoding is safe for all target systems
+1. In particular sanitize all output used for operating system commands
 
-#### Contextual output encoding
+#### 2. Contextual output encoding
 
 Contextual output encoding of data is based on how it will be utilized by the target.
 The specific methods vary depending on the way the output data is used, such as HTML entity encoding.
 
-* Contextually encode all data returned to the client from untrusted sources
-* Contextually encode all output of untrusted data to queries for SQL, XML, and LDAP
+1. Contextually encode all data returned to the client from untrusted sources
+1. Contextually encode all output of untrusted data to queries for SQL, XML, and LDAP
 
 #### References
 

draft/06-design/02-web-app-checklist/05-validate-inputs.md

@@ -24,37 +24,37 @@ Refer to proactive control [C5: Validate All Inputs][control5]
 for more context from the OWASP Top 10 Proactive Controls project,
 and use the list below as suggestions for a checklist that has been tailored for the individual project.
 
-#### Syntax and semantic validity
-
-* Identify all data sources and classify them into trusted and untrusted
-* Validate all input data from untrusted sources such as client provided data
-* Encode input to a common character set before validating
-* Specify character sets, such as UTF-8, for all input sources
-* If the system supports UTF-8 extended character sets then validate after UTF-8 decoding is completed
-* Verify that protocol header values in both requests and responses contain only ASCII characters
-* Validate data from redirects
-* Validate data range and also data length
-* Utilize canonicalization to address obfuscation attacks
-* All validation failures should result in input rejection
-
-#### Libraries and frameworks
-
-* Conduct all input validation on a trusted system
-* Use a centralized input validation library or framework for the whole application
-* If the standard validation routine cannot address some inputs then use extra discrete checks
-* If any potentially hazardous input _must_ be allowed then implement additional controls
-* Validate for expected data types using an allow-list rather than a deny-list
-
-#### Validate serialized data
-
-* Implement integrity checks or encryption of the serialized objects
+#### 1. Syntax and semantic validity
+
+1. Identify all data sources and classify them into trusted and untrusted
+1. Validate all input data from untrusted sources such as client provided data
+1. Encode input to a common character set before validating
+1. Specify character sets, such as UTF-8, for all input sources
+1. If the system supports UTF-8 extended character sets then validate after UTF-8 decoding is completed
+1. Verify that protocol header values in both requests and responses contain only ASCII characters
+1. Validate data from redirects
+1. Validate data range and also data length
+1. Utilize canonicalization to address obfuscation attacks
+1. All validation failures should result in input rejection
+
+#### 2. Libraries and frameworks
+
+1. Conduct all input validation on a trusted system[^SCP1]
+1. Use a centralized input validation library or framework for the whole application
+1. If the standard validation routine cannot address some inputs then use extra discrete checks
+1. If any potentially hazardous input _must_ be allowed then implement additional controls
+1. Validate for expected data types using an allow-list rather than a deny-list
+
+#### 3. Validate serialized data
+
+1. Implement integrity checks or encryption of the serialized objects
     to prevent hostile object creation or data tampering
-* Enforce strict type constraints during deserialization before object creation;
+1. Enforce strict type constraints during deserialization before object creation;
     typically a definable set of classes is expected
-* Isolate features that deserialize so that they run in very low privilege environments such as temporary containers
-* Log security deserialization exceptions and failures
-* Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize
-* Monitor deserialization, for example alerting if a user agent constantly deserializes
+1. Isolate features that deserialize so that they run in very low privilege environments such as temporary containers
+1. Log security deserialization exceptions and failures
+1. Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize
+1. Monitor deserialization, for example alerting if a user agent constantly deserializes
 
 #### References
 
@@ -73,5 +73,6 @@ then [submit an issue][issue060205] or [edit on GitHub][edit060205].
 [edit060205]: https://github.com/OWASP/www-project-developer-guide/blob/main/draft/06-design/02-web-app-checklist/05-validate-inputs.md
 [proactive10]: https://owasp.org/www-project-proactive-controls/
 [sanitizer]: https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer
+[^SCP1]: maybe this
 
 \newpage