Skip to content

Commit

Permalink
Expriment with numbered guidelines
Browse files Browse the repository at this point in the history
  • Loading branch information
@Gudahtt
Gudahtt committed Nov 3, 2023
1 parent 5c9f367 commit 2154c1d
Showing 1 changed file with 69 additions and 69 deletions.
138 changes: 69 additions & 69 deletions docs/secure-coding-guidelines.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -14,123 +14,123 @@ The guidelines in this policy were gathered primarily from the [OWASP Top 10](ht

## Guidelines

### 1 Input from Users and Third Party Services
### 1 – Input from Users and Third Party Services

#### 1.1 Data Validation and Sanitization
#### 1.1 – Data Validation and Sanitization

1. Always validate and sanitize user inputs and reject any input that does not pass validation, such as:
* 1.1.1: Always validate and sanitize user inputs and reject any input that does not pass validation, such as:
1. Checking the type is what we expect: (e.g. is a javascript object being passed in when a string is expected)
2. Checking if the value is what within a range we expect: (e.g. is a negative number being provided when a positive one is expected)
3. Checking if the format is what we expect: (e.g. do we expect a `0x` prefixed hex string but an alphanumeric string is provided instead)
4. Checking if a value matches an allowed set of constants (e.g. is the value one of the few possible numbers we expect)
2. Validate and sanitize data from external sources before rendering it in the application's UI
3. Preference should be given to libraries and frameworks that support input validation
4. Avoid dynamic code execution with untrusted data to prevent injection attacks
* 1.1.2: Validate and sanitize data from external sources before rendering it in the application's UI
* 1.1.3: Preference should be given to libraries and frameworks that support input validation
* 1.1.4: Avoid dynamic code execution with untrusted data to prevent injection attacks

#### 1.2 Content Security
#### 1.2 – Content Security

1. Verify the content type of external data to ensure it matches expectations
2. Enforce proper type checking, file type validation for file/media uploads and rendering third party content
3. Implement Content Security Policies (CSP) to mitigate XSS attacks when rendering external data
* 1.2.1: Verify the content type of external data to ensure it matches expectations
* 1.2.2: Enforce proper type checking, file type validation for file/media uploads and rendering third party content
* 1.2.3: Implement Content Security Policies (CSP) to mitigate XSS attacks when rendering external data

#### 1.3 Data Serialization
#### 1.3 – Data Serialization

1. Recommend using pure data formats such as CSV, JSON for serialization to avoid deserialization attacks
* 1.3.1: Recommend using pure data formats such as CSV, JSON for serialization to avoid deserialization attacks

### 2 Data Persistence & Encryption
### 2 – Data Persistence & Encryption

#### 2.1 Data Classification
#### 2.1 – Data Classification

1. Classify the data in your application into at least two groups:
2. **Non-sensitive** data (e.g. publicly available, transactions, app theme settings, etc…)
3. **Sensitive** data (e.g. passwords, keys)
* 2.1.1: Classify the data in your application into at least two groups:
* 2.1.2: **Non-sensitive** data (e.g. publicly available, transactions, app theme settings, etc…)
* 2.1.3: **Sensitive** data (e.g. passwords, keys)

#### 2.2 Data Security
#### 2.2 – Data Security

1. Encrypt **sensitive** data prior to persisting
2. Limit the amount of time **sensitive** data is decrypted
3. Do not bundle API tokens in client side applications unless you intend for them to be publicly accessible
* 2.2.1: Encrypt **sensitive** data prior to persisting
* 2.2.2: Limit the amount of time **sensitive** data is decrypted
* 2.2.3: Do not bundle API tokens in client side applications unless you intend for them to be publicly accessible

#### 2.3 Encryption
#### 2.3 – Encryption

1. **Sensitive** data should be secured at rest and in-transit using standard encryption protocols (e.g. cryptography libraries, OS level key management systems, https, etc…)
2. Cryptography of **sensitive** data should meet a minimum standard established by the security team during a threat assessment and annual reviews
* 2.3.1: **Sensitive** data should be secured at rest and in-transit using standard encryption protocols (e.g. cryptography libraries, OS level key management systems, https, etc…)
* 2.3.2: Cryptography of **sensitive** data should meet a minimum standard established by the security team during a threat assessment and annual reviews

#### 2.4 Passwords
#### 2.4 – Passwords

1. Passwords used to decrypt content should adhere to security team recommendations during a threat assessment and annual reviews.
* 2.4.1: Passwords used to decrypt content should adhere to security team recommendations during a threat assessment and annual reviews.

### 3 Logging & Error Handling
### 3 – Logging & Error Handling

#### 3.1 Logging
#### 3.1 – Logging

1. Secrets and **sensitive** data should not be logged
2. Console logging should be removed from production code using linters
* 3.1.1: Secrets and **sensitive** data should not be logged
* 3.1.2: Console logging should be removed from production code using linters

#### 3.2 Error Handling
#### 3.2 – Error Handling

1. All errors should be handled
2. Errors should not leak data and be made more generic. This is especially important for code which handles data classified as **sensitive**.
3. Production versions of applications shall have logging disabled
* 3.2.1: All errors should be handled
* 3.2.2: Errors should not leak data and be made more generic. This is especially important for code which handles data classified as **sensitive**.
* 3.2.3: Production versions of applications shall have logging disabled

### 4 Third Party Integrations & Applications
### 4 – Third Party Integrations & Applications

#### 4.1 Authentication and Authorization
#### 4.1 – Authentication and Authorization

1. Implement access controls and authentication mechanisms for accessing external data
2. Store and manage API keys securely when accessing external sources
3. API keys used in client applications shall have a reduced scope adhering to Principle of Least Privilege
4. If an API key is not intended to be publicly accessible, do not use it in a client application
* 4.1.1: Implement access controls and authentication mechanisms for accessing external data
* 4.1.2: Store and manage API keys securely when accessing external sources
* 4.1.3: API keys used in client applications shall have a reduced scope adhering to Principle of Least Privilege
* 4.1.4: If an API key is not intended to be publicly accessible, do not use it in a client application

#### 4.2 Integration/Application Integrity
#### 4.2 – Integration/Application Integrity

1. Monitor integrations/applications for changes and security issues.
* 4.2.1: Monitor integrations/applications for changes and security issues.

#### 4.3 Permissions
#### 4.3 – Permissions

1. All applications/dapps/snaps shall adhere to the following to Principle of Least Privilege with a default state of allowing no permissions
2. Users shall provide consent for required permissions of applications/dapps/snaps
* 4.3.1: All applications/dapps/snaps shall adhere to the following to Principle of Least Privilege with a default state of allowing no permissions
* 4.3.2: Users shall provide consent for required permissions of applications/dapps/snaps

### 5 Dependency Management
### 5 – Dependency Management

#### 5.1 Dependency Integrity
#### 5.1 – Dependency Integrity

1. Use Dependabot to keep all dependencies up to date and to automate checks for updates
2. Pin dependency versions or use a yarn.lock file
* 5.1.1: Use Dependabot to keep all dependencies up to date and to automate checks for updates
* 5.1.2: Pin dependency versions or use a yarn.lock file

#### 5.2 Avoid Deprecated and Unmaintained Packages
#### 5.2 – Avoid Deprecated and Unmaintained Packages

1. Using Socket.dev to check the health and maintenance status of dependencies and seek alternatives when necessary
* 5.2.1: Using Socket.dev to check the health and maintenance status of dependencies and seek alternatives when necessary

#### 5.3 Review Dependency Licenses
#### 5.3 – Review Dependency Licenses

1. Ensure dependencies' licenses align with your project's requirements
* 5.3.1: Ensure dependencies' licenses align with your project's requirements

#### 5.4 Reduce Dependencies and Keep Them Minimal
#### 5.4 – Reduce Dependencies and Keep Them Minimal

1. Minimize dependencies to reduce potential vulnerabilities
* 5.4.1: Minimize dependencies to reduce potential vulnerabilities

#### 5.5 Audit and Monitor Dependencies
#### 5.5 – Audit and Monitor Dependencies

1. Projects should use the npm audit, Dependabot and Socket.dev tooling for periodic automated auditing of dependencies
* 5.5.1: Projects should use the npm audit, Dependabot and Socket.dev tooling for periodic automated auditing of dependencies

#### 5.6 LavaMoat
#### 5.6 – LavaMoat

1. LavaMoat allow-scripts should be enabled on all projects
2. LavaMoat runtime should be enabled on all projects
* 5.6.1: LavaMoat allow-scripts should be enabled on all projects
* 5.6.2: LavaMoat runtime should be enabled on all projects

### 6 Operations & Infrastructure
### 6 – Operations & Infrastructure

#### 6.1 Project secrets
#### 6.1 – Project secrets

1. Project secrets should be generated and shared using a password management system (1Password) and access to that system should follow the Principle of Least Authority
2. Build systems needing access to project secrets should store secrets in specific secret storage and obscured once placed into system
* 6.1.1: Project secrets should be generated and shared using a password management system (1Password) and access to that system should follow the Principle of Least Authority
* 6.1.2: Build systems needing access to project secrets should store secrets in specific secret storage and obscured once placed into system

#### 6.2 Application Integrity
#### 6.2 – Application Integrity

1. Application should be distributed through approved store portals (GitHub, App Store, Play Store, Firefox Store, Chrome Store)
2. Each distribution channel shall have provide release verifiability (certificate signing approval, hash verification)
* 6.2.1: Application should be distributed through approved store portals (GitHub, App Store, Play Store, Firefox Store, Chrome Store)
* 6.2.2: Each distribution channel shall have provide release verifiability (certificate signing approval, hash verification)

#### 6.3 Auditability
#### 6.3 – Auditability

1. All systems supporting the application shall have capability to audit modifications to the system
* 6.3.1: All systems supporting the application shall have capability to audit modifications to the system

0 comments on commit 2154c1d

Please sign in to comment.