#90 Adding identifiers for each headline in the checklist

.wordlist-en.txt

@@ -1,3 +1,4 @@
+ACM
 AEAD
 AES
 APIT
@@ -28,10 +29,13 @@ Bluesky
 Brømsø
 CAPEC
 CCM
+CEC
 CFB
 CISO
 CMS
 CMSeeK
+COE
+CP
 CPE
 CRL
 CRS
@@ -82,6 +86,7 @@ DotNet
 DrHEADer
 Dracon
 ECB
+EE
 ENISA
 ESAPI
 Ebihara
@@ -90,6 +95,7 @@ Elie
 EscapeAll
 Exploitability
 FIPS
+FV
 Flaxman
 GCM
 GCP
@@ -144,6 +150,7 @@ Kubeaudit
 Kubernetes
 Kulkarni
 LDAP
+LF
 LFD
 LINDDUN
 LINNDUN
@@ -201,6 +208,7 @@ OpenID
 OpenJDK
 PCI
 PDFs
+PDR
 PID
 PIDs
 PKI
@@ -233,13 +241,19 @@ SBOM
 SBOMs
 SBT
 SCA
+SCM
 SCP
+SDA
+SDC
 SDLC
 SDLCs
 SECCOMP
 SELinux
+SFL
 SIEM
 SKF
+SL
+SLD
 SMS
 SNYK
 SPOA
@@ -249,6 +263,7 @@ SSLyze
 SSO
 SSP
 SSRF
+SSV
 SVG
 SaaSBOM
 Saad
@@ -297,6 +312,7 @@ VDR
 VM
 VPN
 VPNs
+VSD
 VWAD
 Vandana
 VerSprite
@@ -542,4 +558,4 @@ wrongsecrets
 wstg
 wtf
 www
-xsaero
+xsaero

docs/en/04-design/02-web-app-checklist/01-secure-by-default.md

@@ -7,7 +7,7 @@ Refer to proactive control [C5: Secure By Default Configurations][control5] and
 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.
 
-#### 1. System configuration
+#### 1. System configuration (SC)
 
 1. Restrict applications, processes and service accounts to the least privileges possible
 2. Code which defines the infrastructure should follow the principle of least privilege.
@@ -31,7 +31,7 @@ the
 13. Remove or restrict access to internal application and system documentation (such as for internal APIs) as this can
     reveal backend system or other useful information to attackers
 
-#### 2. File Management
+#### 2. File management (FM)
 
 1. Turn off directory listings
 2. Do not save files in the same web context as the application
@@ -40,7 +40,7 @@ the
 5. Restrict access to files or other resources, including those outside the application's direct control using an allow list
     or the equivalent thereof.
 
-#### 3. Cloud security
+#### 3. Cloud security (CS)
 
 1. Enforce JIT (Just-In-Time) access management
 2. Use security vetted container images that is scanned for package and component vulnerabilities and pulled from a private

docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md

@@ -33,7 +33,7 @@ and use them as the starting point for a checklist that is tailored for the tech
 
 In addition consider the following extra checks for frameworks and libraries.
 
-#### 1. Security Frameworks and Libraries
+#### 1. Security frameworks and libraries (SFL)
 
 1. Ensure servers, frameworks and system components are running the latest approved versions and patches
 2. Use libraries and frameworks from trusted sources that are actively maintained and widely used

docs/en/04-design/02-web-app-checklist/03-secure-database-access.md

@@ -4,7 +4,7 @@ Refer to proactive control [C3: Validate all Input & Handle Exceptions][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.
 
-#### 1. Secure queries
+#### 1. Secure queries (SQ)
 
 1. Use Query Parameterization to prevent untrusted input being interpreted as part of a SQL command
 2. Use strongly typed parameterized queries
@@ -14,7 +14,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 6. Connection strings should not be hard coded within the application
 7. Connection strings should be stored in a separate configuration file on a trusted system and they should be encrypted
 
-#### 2. Secure configuration
+#### 2. Secure database configuration (SDC)
 
 1. The application should use the lowest possible level of privilege when accessing the database
 2. Use stored procedures to abstract data access and allow for the removal of permissions to the base tables in the database
@@ -23,7 +23,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 5. Remove unnecessary default vendor content, for example sample schemas
 6. Disable any default accounts that are not required to support business requirements
 
-#### 3. Secure authentication
+#### 3. Secure database authentication (SDA)
 
 1. Remove or change all default database administrative passwords
 2. The application should connect to the database with different credentials for every trust distinction

docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md

@@ -11,7 +11,7 @@ Refer to proactive control [C3: Validate all Input & Handle Exceptions][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.
 
-#### 1. Character encoding and canonicalization
+#### 1. Character encoding and canonicalization (CEC)
 
 1. Apply output encoding just before the content is passed to the target system
 2. Conduct all output encoding on a trusted system
@@ -22,7 +22,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 7. In particular sanitize all output used for operating system commands
 8. Sanitize potentially dangerous characters before using the data to call another service
 
-#### 2. Contextual output encoding
+#### 2. Contextual output encoding (COE)
 
 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.

docs/en/04-design/02-web-app-checklist/05-validate-inputs.md

@@ -8,7 +8,7 @@ Refer to proactive control [C3: Validate All Input & Handle Exceptions][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.
 
-#### 1. Syntax and semantic validity
+#### 1. Syntax and semantic validity (SSV)
 
 1. Identify all data sources and classify them into trusted and untrusted
 2. Validate all input data from untrusted sources such as client provided data
@@ -21,7 +21,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 9. All validation failures should result in input rejection
 10. Validate all input against an allowlist of characters, whenever possible
 
-#### 2. Libraries and frameworks
+#### 2. Libraries and frameworks (LF)
 
 1. Conduct all input validation on a trusted system [^SCP1]
 2. Use a centralized input validation library or framework for the whole application
@@ -30,7 +30,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 5. Validate for expected data types using an allow-list rather than a deny-list
 6. Do not allow the application to issue commands directly to the Operating System
 
-#### 3. Validate serialized data
+#### 3. Validate serialized data (VSD)
 
 1. Implement integrity checks or encryption of the serialized objects
     to prevent hostile object creation or data tampering
@@ -41,7 +41,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 5. Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize
 6. Monitor deserialization, for example alerting if a user agent constantly deserializes
 
-#### 4. File validation
+#### 4. File validation (FV)
 
 1. Do not pass user supplied data directly to any dynamic include function
 2. Limit the type of files that can be uploaded to only those types that are needed for business purposes

docs/en/04-design/02-web-app-checklist/06-digital-identity.md

@@ -6,7 +6,7 @@ Refer to proactive control [C7: Secure Digital Identities][control7] and its [ch
 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.
 
-#### 1. Authentication
+#### 1. Authentication (A)
 
 1. Require authentication for all pages and resources, except those specifically intended to be public
 2. Require authentication before allowing a file to be uploaded
@@ -35,7 +35,7 @@ and use the list below as suggestions for a checklist that has been tailored for
    differ, depending on whether a username exist or not. Use a DB transaction that looks for a fake user profile in case the
    username doesn't exist
 
-#### 2. Passwords
+#### 2. Passwords (P)
 
 1. If your application manages a credential store, use cryptographically strong one-way salted hashes
 2. Password hashing must be implemented on a trusted system
@@ -56,7 +56,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 15. Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in the
     browser's storage mechanisms
 
-#### 3. Session Management
+#### 3. Session Management (SM)
 
 1. Use the server or framework's session management controls
 2. Session identifier creation must always be done on a trusted system

docs/en/04-design/02-web-app-checklist/07-access-controls.md

@@ -5,7 +5,7 @@ Refer to proactive control [C1: Implement Access Controls][control1] and its [ch
 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.
 
-#### 1. Implement Access Control
+#### 1. Access control (AC)
 
 1. Design access control / authorization thoroughly up-front
 2. Force all requests to go through access control checks unless public
@@ -27,7 +27,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 15. Server side implementation and presentation layer representations of access control rules should not differ in such a way
     that they allow for business functionality and rules to be compromised
 
-#### 2. Access control Management
+#### 2. Access control management (ACM)
 
 1. Limit the number of transactions a single user or device can perform in a given period of time,
     low enough to deter automated attacks but above the actual business requirement

docs/en/04-design/02-web-app-checklist/08-protect-data.md

@@ -6,7 +6,7 @@ Refer to proactive control [C2: Use Cryptography to Protect Data][control2] and
 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.
 
-#### 1. Cryptographic practices
+#### 1. Cryptographic practices (CP)
 
 1. Use peer reviewed and open solution cryptographic modules
 2. All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system
@@ -17,7 +17,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 6. Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard
 7. Don't implement your own cryptographic protocols or routines. Use existing security vetted library and frameworks
 
-#### 2. Data protection
+#### 2. Data protection (DP)
 
 1. Classify data according to the level of sensitivity
 2. Implement appropriate access controls for sensitive data
@@ -28,7 +28,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 7. Set a referrer policy to prevent leakage of sensitive data to third-party services via the 'Referer' HTTP request header
     field. This can be done using the Referrer-Policy HTTP response header field or via HTML element attributes
 
-#### 3. Secret Management
+#### 3. Secret and credential management (SCM)
 
 1. Establish and utilize a policy and process for how cryptographic keys will be managed
 2. Ensure that any secret key is protected from unauthorized access
@@ -39,7 +39,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 7. Scan code repositories to detect accidentally added secrets and credentials
 8. Log all authorized access to a secret key for forensic purposes
 
-#### 4. Memory management
+#### 4. Memory management (MM)
 
 1. Explicitly initialize all variables and data stores
 2. Check that any buffers are as large as specified
@@ -51,14 +51,14 @@ and use the list below as suggestions for a checklist that has been tailored for
 8. Protect shared variables and resources from inappropriate concurrent access
 9. Avoid the use of known vulnerable functions
 
-#### 5. Protect Data at Rest
+#### 5. Protect Data at Rest (PDR)
 
 1. Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification
 2. Purge sensitive data when that data is no longer required
 3. Protect all cached or temporary copies of sensitive data from unauthorized access
 4. Purge those temporary copies of sensitive data as soon as they are no longer required
 
-#### 6. Protect Data in Transit
+#### 6. Protect Data in Transit (PDT)
 
 1. Encrypt data in transit
 2. Ensure secure communication channels are properly configured

docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md

@@ -5,7 +5,7 @@ Refer to proactive control [C9: Implement Security Logging and Monitoring][contr
 and its [cheatsheets][csproactive-c9] 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.
 
-#### 1. Security logging
+#### 1. Security logging (SL)
 
 1. Log submitted data that is outside of an expected numeric range
 2. Log all apparent tampering events, that involve changes to data and state that should not be modifiable
@@ -21,7 +21,7 @@ and use the list below as suggestions for a checklist that has been tailored for
 12. Log all backend TLS connection failures
 13. Log cryptographic module failures
 
-#### 2. Security logging design
+#### 2. Security logging design (SLD)
 
 1. Protect log integrity
 2. Ensure log entries that include untrusted data will not execute as code in the intended log viewing interface or software
@@ -38,7 +38,7 @@ and use the list below as suggestions for a checklist that has been tailored for
   identity of the account holder, trace id and span id that can be correlated against the end user's ip, event outcome,
   event description
 
-#### 3. Monitoring
+#### 3. Monitoring (M)
 
 1. Effective monitoring and alerting should be established to detect and respond to suspicious activities quickly
 2. Account for attack patterns that bypass standard lockouts, such as using the same passwords against multiple user accounts

docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md

@@ -6,7 +6,7 @@ Refer to proactive control [C3: Validate all Input & Handle Exceptions][control3
 and its [cheatsheets][csproactive-c10] 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.
 
-#### 1. Errors and exceptions
+#### 1. Errors and exceptions (EE)
 
 1. Manage exceptions in a centralized manner to avoid duplicated try/catch blocks in the code
 2. Ensure that all unexpected behavior is correctly handled inside the application