| Policy |
| ☑️ | recognize-policies.yaml is up-to-date with the correct versions of policy |
| General |
| ☑️ | Automation has been applied to make sure we don't have to manually execute repeating tasks |
| ☑️ | The quality of our software adheres to the Recognize quality guideline |
| ☑️ | Deviations from policy have been consulted with the Head of Development and consent has been given |
| Development |
| ☑️ | No unsafe dependencies are used within the project |
| ☑️ | Static Application Security Testing (SAST) is used to test application code or binaries for known security flaws |
| ☑️ | Automatic tooling is used to scan (external) dependencies |
| ☑️ | Validation happens on the side of the server, and client-side validation is used as a complement |
| Web |
| ☑️ | Web traffic is redirected from HTTP to HTTPS |
| ☑️ | The minimum TLS-version supported by the web server is 1.2 |
| ☑️ | Only strong ciphers are supported by the web server |
| ☑️ | No version information is return in the headers of a response |
| ☑️ | No debugging information is returned to the user in any way on acceptance and production environments |
| ☑️ | The application uses CSRF-tokens when cookies are used for authentication |
| ☑️ | Only secure cookies are returned from the server |
| ☑️ | User data (including access tokens) is removed from the device when a user logs out |
| ☑️ | The Referrer-Policy-header has been set correctly |
| ☑️ | The Cache-Control-header has been set correctly |
| ☑️ | The X-Frame-Options-header has been set correctly |
| ☑️ | The Strict-Transport-Security-header has been set correctly |
| ☑️ | The X-Content-Type-Options-header has been set correctly |
| ☑️ | The X-XSS-Protection-header has been set correctly |
| ☑️ | The Permissions-Policy-header has been set correctly |
| ☑️ | The Content-Security-Policy-header has been set correctly |
| ☑️ | DNSSEC is enabled for application domains that support it. |
| ☑️ | The CORS-policy has been set correctly |
| Mobile |
| ☑️ | On iOS & Android, user data should be stored in a secure container |
| ☑️ | On iOS & Android, user data (including access tokens) is removed from the device when a user logs out |
| ☑️ | On iOS & Android, applications should only request permissions that are strictly required. |
| ☑️ | On Android, it should be considered whether the backup-flag should be set to false |
| ☑️ | On Android, intents that are opened from external URLs, should have the autoVerify-flag set |
| ☑️ | On Android, applications are signed with a v2 or newer signature |
| Authentication & Authorization |
| ☑️ | Single sign-on is implemented with standardized libraries, if available |
| ☑️ | Single sign-on tokens are verified, to ensure that they are issued by the correct organization |
| ☑️ | No custom solution is used for the implementation of local accounts |
| ☑️ | Passwords are hashed with an approved hashing mechanism |
| ☑️ | Passwords are sent over an encrypted, TLS, connection |
| ☑️ | If RBAC is used, roles are checked in the backend. |
| ☑️ | If RBAC is used, access is only granted when roles are explicitly specified |
| ☑️ | Applications with login functionality, should provide a logout option |
| Infrastructure |
| ☑️ | Databases should not be publicly accessible (including Azure services) |
| ☑️ | Databases password are cryptographically randomly created and be at least 20 characters long |
| ☑️ | Stored data should be encrypted at rest and if sent over the internet, encrypted in transit |
| ☑️ | Web apps that are publicly accessible should be served over a secure connection |
| ☑️ | Communication with key vault services should occur over a secure connection |
| ☑️ | Secret values used in CI-scripts should be marked as 'secure' in the corresponding CI-environment |
| ☑️ | Service principals should be rotated every 12 months |
| Environments |
| ☑️ | Development environment is not publicly accessible |
| ☑️ | Acceptance and production environments have all security measurements in place as specified in this policy |
| Encryption & Secrets |
| ☑️ | Secrets are stored in a secure environment |
| ☑️ | Passwords requirements meet the VolkerWessels Authenticatiebeleid |
| ☑️ | Connections are encrypted with TLS and use secure ciphers |