From 0bf44c6af804fc9b08268c0f3b399f1eb5551920 Mon Sep 17 00:00:00 2001 From: sydseter Date: Thu, 7 Aug 2025 12:53:04 +0200 Subject: [PATCH 1/3] Adding identifieras for each headline in the checklist --- .../02-web-app-checklist/01-secure-by-default.md | 6 +++--- .../02-web-app-checklist/02-frameworks-libraries.md | 2 +- .../03-secure-database-access.md | 6 +++--- .../02-web-app-checklist/04-encode-escape-data.md | 4 ++-- .../02-web-app-checklist/05-validate-inputs.md | 8 ++++---- .../02-web-app-checklist/06-digital-identity.md | 6 +++--- .../02-web-app-checklist/07-access-controls.md | 4 ++-- .../02-web-app-checklist/08-protect-data.md | 12 ++++++------ .../02-web-app-checklist/09-logging-monitoring.md | 6 +++--- .../10-handle-errors-exceptions.md | 2 +- 10 files changed, 28 insertions(+), 28 deletions(-) diff --git a/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md b/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md index 892babc2..46543bd5 100644 --- a/docs/en/04-design/02-web-app-checklist/01-secure-by-default.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md b/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md index 845f3dee..42a8b2c7 100644 --- a/docs/en/04-design/02-web-app-checklist/02-frameworks-libraries.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md b/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md index 024bb810..bc1017e7 100644 --- a/docs/en/04-design/02-web-app-checklist/03-secure-database-access.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md b/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md index 74e560e3..400887e6 100644 --- a/docs/en/04-design/02-web-app-checklist/04-encode-escape-data.md +++ b/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. diff --git a/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md b/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md index 4535a569..5d0794f6 100644 --- a/docs/en/04-design/02-web-app-checklist/05-validate-inputs.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md b/docs/en/04-design/02-web-app-checklist/06-digital-identity.md index 8f6b6b46..82abf152 100644 --- a/docs/en/04-design/02-web-app-checklist/06-digital-identity.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/07-access-controls.md b/docs/en/04-design/02-web-app-checklist/07-access-controls.md index 0a0d941b..51d83356 100644 --- a/docs/en/04-design/02-web-app-checklist/07-access-controls.md +++ b/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. Implement 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 diff --git a/docs/en/04-design/02-web-app-checklist/08-protect-data.md b/docs/en/04-design/02-web-app-checklist/08-protect-data.md index 12c9a9f2..9a7a5beb 100644 --- a/docs/en/04-design/02-web-app-checklist/08-protect-data.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md b/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md index d97cbb05..abb35b8f 100644 --- a/docs/en/04-design/02-web-app-checklist/09-logging-monitoring.md +++ b/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 diff --git a/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md b/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md index 04b4548c..d9c5387f 100644 --- a/docs/en/04-design/02-web-app-checklist/10-handle-errors-exceptions.md +++ b/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 From f67e30a1ccb36459a363947040a6d337e437bbb2 Mon Sep 17 00:00:00 2001 From: sydseter Date: Thu, 7 Aug 2025 12:59:33 +0200 Subject: [PATCH 2/3] Add missing words to the wordlist --- .wordlist-en.txt | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/.wordlist-en.txt b/.wordlist-en.txt index af76f3d2..8be8120f 100644 --- a/.wordlist-en.txt +++ b/.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 \ No newline at end of file From 11b9a50dff3e36821131afff8c06149dfa6f0cf1 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Thu, 7 Aug 2025 13:08:56 +0200 Subject: [PATCH 3/3] Update 07-access-controls.md --- docs/en/04-design/02-web-app-checklist/07-access-controls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/04-design/02-web-app-checklist/07-access-controls.md b/docs/en/04-design/02-web-app-checklist/07-access-controls.md index 51d83356..1eb65b56 100644 --- a/docs/en/04-design/02-web-app-checklist/07-access-controls.md +++ b/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 (AC) +#### 1. Access control (AC) 1. Design access control / authorization thoroughly up-front 2. Force all requests to go through access control checks unless public