Requirements from Witekio Security Framework

Design

Id	Description	Relevant for Kamea ?	Kamea support	Comment
Handling sensitive data
R.Data_collection	Any data collected from the user must be clearly identified, and their collection, use, and storage in the infrastructure must be justified by the system’s functionality.	Enforcing	Yes	Only the user account, used for authorization
R.Data_protection	The transport and storage of data must be adequately protected in confidentiality and integrity	Enforcing	Yes	Secure communication with external components (TLS based) ; Internal communication channels are unreachable except through specifically authenticated endpoints.
R.Data_protection_infra	Any data stored in the infrastructure must be applied a policy that limits the risks of theft, leakage, and misuse	Enforcing	Yes	Relies on the cloud provider security
R.Remote_commands	The remote commands that can be sent from the infrastructure to the things must be constrained to the strict minimum required to ensure the system’s functionality. In particular, in the production environment, no command dedicated to the test or debugging of the system must remain active.	No	NA
R.Commands_Integrity	The things must authenticate their interlocutors before interpreting any command (see also 3.2.1). Then the integrity of the flow of commands must be checked.	No
R.Commands_Confidentiality	Any command that includes sensitive values must also be encrypted.	Enforcing	Yes	All administrative commands are sent through encrypted TLS channels.
R.Sensitive_processes	All the sensitive processes must be achieved in an environment that reduces the risks of attack (e.g., key generation, software build, signature, …)	Enforcing	Yes	Provide information regarding deployment (--> Terraform) and protection of secrets
Use standard tools and specifications
R.Well-tried_components	All communications and processing must be achieved using well-known and used standards. This is critical when it comes to cryptography and communications, where only protocols and algorithms that are largely used and for which the security properties are understood and reviewed by the security community shall be used. For cryptography, protocols, and communications, only reviewed and or evaluated implementations should be used.	Enforcing	Yes
R.Third_party	All 3rd party libraries and software components used in the system shall be monitored all along with the system’s life for new vulnerabilities. Organizational measures must be set up for this monitoring, impact analysis, and corrective actions.	Enforcing	Yes	Not in place yet
Secure development methods
R.Tests	A sound functional and unit testing campaign must be set up to guarantee the quality of the produced code.	Supporting	Yes	min. 85% of code coverage, and several layers of tests (unit, integration, e2e)
R.Fuzzing	A fuzz-testing campaign can be set up to detect anomalous behaviors of the system, especially in the case of malformed input data.	Supporting	No

Cryptography

Id	Description	Relevant for Kamea ?	Kamea support	Comment
Key management
R.Secrets_protection	Private and secret keys should be protected in confidentiality (and when necessary, in integrity) during their whole life from generation to destruction, using a combination of organizational and technical means.	Enforcing	Yes	Secrets are handled directly by Azure resources. Access to secrets is controlled through Azure authorization and Kamea authorization systems
R.Keys_linkage	The right association between secrets and their legitimate owners must be enforced to rule out man-in-the-middle attacks. This can be done by enforcing the use of cryptographic proof-of-possession mechanisms for all public keys.	Enforcing	Yes	Relies on the cloud provider security
R.Master_secrets	The keys must be segregated by usage and by identity, and the system must be conceived in such a way that the compromission of a secret does not endanger other keys, to limit lateral propagation of an attack.	Enforcing	?	Relies on the cloud provider security
R.Unique_keys	When using asymmetric cryptography, the private keys must be unique per device and usage.	Supporting	Yes
R.Symmetric_keys_derivation	When using symmetric cryptography, key derivation functions must be used to use one single key for a specific device and usage.	Enforcing	Yes	TLS
R.Keys_lifetime	Each key must have a limited lifetime, set up according to the probability and potential impacts of its compromission.	Supporting	Yes
R.Revocation	It is advised to set up a key revocation mechanism	Supporting	?	Possible in Azure, but not forced through Kamea
Authentication
R.Auth_sensitive_actions	If the system allows remote commands or remote configuration from the cloud to the things, then an authentication step must be mandatory before being able to communicate with the things.	No	NA
R.Unique_auth_secrets	The secrets used for authentication (keys or passwords) must be unique per device, even before its first configuration. Therefore, default passwords and/or keys must be avoided at all costs. Alternative solutions may include generating a secret at manufacture then printing it on the device or using a display to communicate the secret to the user at each factory reset.	No	NA
R.Auth_protocols	The authentication protocols must not suffer from any security flaw and prevent replay attacks and brute-force attacks.	Supporting	Yes	Relies on the cloud provider security
R.Password_hashes	Password-based authentication protocols must be implemented in such a way that the reference password is never stored on the devices (be it in clear or in encrypted form). To this end, a key derivation function based on a cryptographic hash algorithm must be used (see for instance https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf ). This primitive must intrinsically take a long time to compute to prevent brute-force attacks.	Enforcing	Yes	Oauth
R.Bruteforce	The number of tries for password authentication must be limited. Whenever this is not possible the delay between two failed password entries must be increased.	?	?	Relies on the cloud provider security
Data confidentiality and Integrity
R.Communication_protection	All sensitive communications between the things and the infrastructure must be protected in confidentiality and integrity using state-of-the-art cryptographic primitives. More specifically: · Critical security parameters (e.g., passwords) must be encrypted in transit, with such encryption appropriate to the properties of the technology, risk, and usage, · The confidentiality of personal data transiting between a device and a service, especially associated services, should be protected, with best practice cryptography. Whereas the definition of “state-of-the-art cryptographic primitive” is intrinsically evolving, the reader is referred for instance to the SOG-IS document Agreed on Cryptographic Mechanisms.	Enforcing	Yes	TLS+MQTTS+…
R.DAR_protection	Any sensitive data stored in the non-volatile memory of the devices (e.g., Flash, EEPROM, SSD, …) must be protected in confidentiality and integrity.	No	NA
R.Volatile_data_protection	Any sensitive data stored in the volatile memory of the devices (RAM) should be protected in confidentiality and integrity.	No	NA
Additional cryptography considerations
R.Update_crypto	Cryptographic algorithms and primitives should be updateable, in case a specific algorithm or mode of operation cryptographic strength is lowered by a new attack or technological breakthrough.	Yes	Yes

Software Security

Id	Description	Relevant for Kamea ?	Kamea support	Comment
Maintain software integrity
R.Minimal_attack_surface	Some system minimizations must be done: only the applications, libraries, and drivers required for achieving the desired functionality must be present in the system. Any portion of software used for debugging and diagnostic must be removed in the production build, especially if it is prone to exposing sensitive data. The code of the applications and libraries should be minimized to the smaller subset necessary for the service/device to operate. NB: when using standard or public libraries, the minimization effort should be balanced with the benefits of using standard, labeled versions of the software packages and libraries. In other words, it is not advised to minimize a library if this process entails that obsolete versions of the library are used in the product.	Enforcing	Yes	Only the production code is deployed
R.Secure_boot_chain	A hardware-backed secure boot verification chain should be used to ensure the integrity and authenticity of the code before its execution. NB: this measure does not protect against software vulnerabilities: it ensures that the executed code has been checked before its execution. Thus, the acquired guarantees are at most as strong as the verification process, which is outside the scope of this guide. This recommendation requires the use of a hardware root of trust.	No	NA
R.Software_integrity_check	If an unauthorized change is detected to the software (either through the secure boot process or later monitoring), the device should alert the user and/or administrator to the issue and should not connect to wider networks than those necessary to perform the alerting function.	No ?	NA ?
Software updates
R.Software_firmware_updates	Software and firmware upgrades must be possible, to deal with new vulnerabilities and correct existing weaknesses. The update should be either automatic (OTA updates) or easy for the user to apply. The devices should check after initialization, and then periodically, whether security updates are available.	Supporting	Yes	Depends on the customer use case and hardware
R.Authentication_versioning	All software and firmware updates must be versioned and authenticated by the developer or a trusted third party. The authenticity verification process must cover both the software itself and its version.	Supporting	?	Depends on the customer use case and hardware
R.Anti-rollback	Rolling back from one version to a strictly anterior one must be forbidden, so that an attacker may not downgrade the security of the system by installing a version where some vulnerability is not covered.	No	NA
R.Local_authenticity_verification	The authenticity of software destined for a component must be checked by the component itself. If it’s not possible the component realizing the authenticity verification must be trusted by the component executing the software through a suitable mechanism (e.g., an authenticated and encrypted secure channel is established between both components). The verification of the authenticity of the updates must use best practice cryptographic mechanisms.	No	NA
R.Software_hardware_versioning	All hardware and software versions must be identifiable easily to determine if an update is needed for some device. Nevertheless, this information should not be made available remotely without a suitable authentication.	Supporting	?	Depends on the customer use case and hardware
Memory isolation
R.Segregation_applications_services	The applications and services running on a device should be segregated from each other as much as possible to mitigate the consequences of the compromission of one of them. This implies the use of a kernel-level resources control mechanism that limits access to system resources (such as memory and peripherals), following a principle of least privilege. Memory spaces of the various application must be distinct, and it should not be possible for an application to read or write in a zone that belongs to another one except by using standardized inter-application communication mechanisms.	No	NA
R.Segregation_multi-user	When using a multi-process and multi-user system each functionality must be supported by a dedicated process run by a dedicated user with the least possible rights for providing the functionality.	No	NA
R.Segregation_processes	When using a multi-process and multi-user system each process interacting with the environment must be run by a specific user with minimal rights: in particular, this user must not have elevated privileges (root or super-user).	No	NA
Software development good practices
R.Up-to-date_tools	Only up-to-date toolchains must be used for building.	Enforcing	Yes	CI/CD images & tools are frequently updated
R.Code_hardening	All relevant protections offered by the building tools (e.g., obfuscation, stack canaries, …) must be used for building.	?	?
R.Build_warnings	A suitable set of warnings must be used for building, and all detected problems must be addressed.	?	?
R.Static_analysis	Static analysis tools should be used to detect runtime errors that may lead to potential code weaknesses.	Enforcing	?	Using SonarCloud
Logging security events
R.Logs_lifetime_access_rights	All security-related events (reboots, successful and failed connections, errors, …) must be logged, and the lifespan of the logs must allow a subsequent analysis.	Enforcing	?	Depends on the customer use case and hardware
R.Read-only_logs	It must not be possible for a user to delete or modify the logs.	Enforcing	?	Depends on the customer use case and hardware
R._Remote_logging	The logs should be exported to a remote location whenever it’s required to protect them.	Supporting	?	Depends on the customer use case and hardware
Additional software security considerations
R.Minimization_access_rights	External users interacting with the devices should have limited rights according to the actions they can legitimately do and their level of authentication. Whenever several user roles exist a link should be enforced between an authenticated user and its role so that the rights associated with the role can be applied to the user.	Supporting	?	Depends on the customer use case and hardware

Hardware Security

Id	Description	Relevant for Kamea ?	Kamea support
Countermeasures against hardware attacks
R.Access_internals	The hardware debugging and programming interfaces (e.g., JTAG, SWD) must be unreachable when the devices are in their operational environment. Depending on the hardware used, this can be achieved either via hardware fuses, using a suitable authentication mechanism on these interfaces, or when none of the above is possible by making physical access to these interfaces as difficult as possible.	No	NA
R.Protect_internal_communication	Any exposed bus on the PCB of the devices should be protected in integrity and confidentiality. Whenever a (volatile or non-volatile) memory is in a separate package from the CPU it should be encrypted if sensitive data are stored on them.	No	NA
R.Protect_hard-coded_device_id	Where a hard-coded unique per device identity is used in a device for security purposes, it shall be implemented in such a way that it resists tampering by means such as physical, electrical, or software.	No	NA
R.secure_RE	It is recommended to use a dedicated certified secure element, or a trusted execution environment, for processing any sensitive data whose confidentiality and integrity must be protected.	No	NA
Random numbers and nonces
R.Cryptographic_RNG	A cryptographic quality random number generator should be available on the devices and used for a security-critical task that requires a good source of entropy (e.g., key generation, challenge generation, initialization vectors for cryptographic algorithms, …).	No	NA
R.Nonces_generation	Each device should be capable of generating unique numbers to be used to prevent replay attacks, either using random values or a suitably protected long-term memory.	No	NA

Network Security

Id	Description	Relevant for Kamea ?	Kamea support	Comment
Accessible ports and services
R.Unknown_origin_requests	No request from an unknown source should be processed to restrict the attack surface. This can be done by cryptographic authentication, or by a network mechanism such as a VPN.	Enforcing	?	Unknown sources must be accepted since Kamea provides a public API
R.Minimization_exposed_services	Only the network services necessary for the proper use of the device should be available.	No	NA
Robustness against denial of service
R.UDP_reflection_attacks	UDP is an ideal medium for DRDOS attacks, and thus must be avoided to that the devices do not contribute to such an attack.	Supporting	?	Currently no usage of UDP
Secure communication protocols
R.Protect_data_in_transit	Standard, proven secure communication protocols (such as TLS, IPSec) must be used.	Enforcing	Yes
Malicious actions detection
R.Network_monitoring	Active monitoring of network incidents should be used to detect and characterize any attempts to compromise the network.	Enforcing	?	Not yet in place

Robustness

Id	Description	Relevant for Kamea ?	Kamea support	Comment
Make systems resilient to outages
R.Outages_resilience	Resilience should be built in the devices and services, considering the possibility of outages of data networks and power.	Enforcing	?	Only managed services are used. Depends on the reliability of the cloud provider
R.Loss_network_power	The devices should remain operating and locally functional in the case of a loss of network access and should recover cleanly in the case of restoration of a loss of power.	Supporting	?	Depends on the customer use case and hardware
R.Re-connection	The devices should connect to networks in an expected, operational and stable state and in an orderly fashion, considering the capability of the infrastructure.	Supporting	?	Depends on the customer use case and hardware
Additional robustness considerations
R.Data_input_validation	The device’s software shall validate data input via user interfaces or transferred via Application Programming Interfaces (APIs) or between networks in services and devices.	Supporting	?	Depends on the customer use case and hardware

OWASP ASVS

Architecture, Design and Threat Modeling

Secure Software Development Lifecycle

Id	Description	level2	level3	cwe	Kamea support ?	Comment
V1.1.1	Verify the use of a secure software development lifecycle that addresses security in all stages of development. (C1)	✓	✓			Too vague
V1.1.2	Verify the use of threat modeling for every design change or sprint planning to identify threats, plan for countermeasures, facilitate appropriate risk responses, and guide security testing.	✓	✓	1053		Too vague
V1.1.3	Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile"	✓	✓	1110		N/A
V1.1.4	Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.	✓	✓	1059		Too vague
V1.1.5	Verify definition and security analysis of the application's high-level architecture and all connected remote services. (C1)	✓	✓	1059		Too vague
V1.1.6	Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls. (C10)	✓	✓	637		Too vague
V1.1.7	Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.	✓	✓	637	²	Too vague

Authentication Architecture

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.2.1	Verify the use of unique or special low-privilege operating system accounts for all application components, services, and servers. (C3)	✓	✓	250	Yes	Yes	Very few technical accounts, their possible operations are limited and their credentials are not accessible
V1.2.2	Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. (C3)	✓	✓	306	Yes	Yes	Every exchange is authenticated
V1.2.3	Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.	✓	✓	306	Yes	Yes	Oauth2
V1.2.4	Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application.	✓	✓	306	Yes	Yes	Validation of user access token on all user-dedicated endpoints

Access Control Architecture

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.4.1	Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.	✓	✓	602	Yes	Yes	Validation of user access token on all user-dedicated endpoints
V1.4.4	Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. (C7)	✓	✓	284	Yes	Yes	Validation of user access token on all user-dedicated endpoints
V1.4.5	Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles. (C7)	✓	✓	275	Yes	Yes	Validation of user access token on all user-dedicated endpoints

Input and Output Architecture

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.5.1	Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other policy compliance.	✓	✓	1029	Yes	Yes	Flux matrix
V1.5.2	Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.	✓	✓	502	Yes	Yes	No communication with untrusted clients + TLS used everywhere
V1.5.3	Verify that input validation is enforced on a trusted service layer. (C5)	✓	✓	602	Yes	Yes	User inputs are always sanitized in the API. Parameterized queries are used in all DB requests
V1.5.4	Verify that output encoding occurs close to or by the interpreter for which it is intended. (C4)	✓	✓	116	?	?	?

Cryptographic Architecture

Id	Description	level2	level3	cwe	Comment
V1.6.1	Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57.	✓	✓	320	Relies on the cloud provider security
V1.6.2	Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.	✓	✓	320	Relies on the cloud provider security
V1.6.3	Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.	✓	✓	320	Relies on the cloud provider security
V1.6.4	Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.	✓	✓	320	Device symmetric must be exposed to customers (after access right validation) in order for the devices to be provisioned

Errors, Logging and Auditing Architecture

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.7.1	Verify that a common logging format and approach is used across the system. (C9)		✓	✓	1009	Yes	No	No specific format used for the logs
V1.7.2	Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation. (C9)		✓	✓		Yes	No	API logs are not sent to an analyzer, but kept on the API server instead

Data Protection and Privacy Architecture

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.8.1	Verify that all sensitive data is identified and classified into protection levels.		✓	✓				Depends on the customer use case
V1.8.2	Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture.		✓	✓				Depends on the customer use case

Communications Architecture

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.9.1	Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers. (C3)		✓	✓	319	Yes	Yes	TLS used for all inner communications
V1.9.2	Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains.		✓	✓	295	Yes	Yes	Azure managed identities are used to connect components to each other

Malicious Software Architecture

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.10.1	Verify that a source code control system is in use, with procedures to ensure that check-ins are accompanied by issues or change tickets. The source code control system should have access control and identifiable users to allow traceability of any changes.		✓	✓	284	?	?	?

Business Logic Architecture

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.11.1	Verify the definition and documentation of all application components in terms of the business or security functions they provide.	✓	✓	1059	Yes	in progress	Documentation not exhaustive
V1.11.2	Verify that all high-value business logic flows, including authentication, session management and access control, do not share unsynchronized state.	✓	✓	362	Yes	Yes	Kamea is stateless
V1.11.3	Verify that all high-value business logic flows, including authentication, session management and access control are thread safe and resistant to time-of-check and time-of-use race conditions.		✓	367	Yes	Yes	Synchronous operations are used sequencially

Secure File Upload Architecture

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.12.2	Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.		✓	✓	646	Yes	No	Kamea uses an Azure Storage account in the same resource group. File are downloaded depending on their original format.

Configuration Architecture

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V1.14.1	Verify the segregation of components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.	✓	✓	923	Depends on the customer
V1.14.2	Verify that binary signatures, trusted connections, and verified endpoints are used to deploy binaries to remote devices.	✓	✓	494	Depends on the customer use case and hardware
V1.14.3	Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.	✓	✓	1104	Yes	No	Not tool in place to validate that
V1.14.4	Verify that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly if the application infrastructure is software defined, such as cloud environment build scripts.	✓	✓				Too vague
V1.14.5	Verify that application deployments adequately sandbox, containerize and/or isolate at the network level to delay and deter attackers from attacking other applications, especially when they are performing sensitive or dangerous actions such as deserialization. (C5)	✓	✓	265	Yes	Yes	Using Docker containers for all deployment operations
V1.14.6	Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.	✓	✓	477	Yes	Yes

Authentication

Password Security

Id	Description	level1	level2	level3	cwe	Comment
V2.1.1	Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). (C6)	✓	✓	✓	521	Relies on the cloud provider security
V2.1.2	Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. (C6)	✓	✓	✓	521	Relies on the cloud provider security
V2.1.3	Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. (C6)	✓	✓	✓	521	Relies on the cloud provider security
V2.1.4	Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.	✓	✓	✓	521	Relies on the cloud provider security
V2.1.5	Verify users can change their password.	✓	✓	✓	620	Relies on the cloud provider security
V2.1.6	Verify that password change functionality requires the user's current and new password.	✓	✓	✓	620	Relies on the cloud provider security
V2.1.7	Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. (C6)	✓	✓	✓	521	Relies on the cloud provider security
V2.1.8	Verify that a password strength meter is provided to help users set a stronger password.	✓	✓	✓	521	Relies on the cloud provider security
V2.1.9	Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. (C6)	✓	✓	✓	521	Relies on the cloud provider security
V2.1.10	Verify that there are no periodic credential rotation or password history requirements.	✓	✓	✓	263	Relies on the cloud provider security
V2.1.11	Verify that "paste" functionality, browser password helpers, and external password managers are permitted.	✓	✓	✓	521	Relies on the cloud provider security
V2.1.12	Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as built-in functionality.	✓	✓	✓	521	Relies on the cloud provider security

General Authenticator Security

Id	Description	level1	level2	level3	cwe	Comment
V2.2.1	Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.	✓	✓	✓	307	Relies on the cloud provider security
V2.2.2	Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.	✓	✓	✓	304	Relies on the cloud provider security
V2.2.3	Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations. The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.	✓	✓	✓	620	Relies on the cloud provider security
V2.2.4	Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates.			✓	308	Relies on the cloud provider security
V2.2.5	Verify that where a Credential Service Provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.			✓	319	Relies on the cloud provider security
V2.2.6	Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.			✓	308	Relies on the cloud provider security
V2.2.7	Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key.			✓	308	Relies on the cloud provider security

Authenticator Lifecycle

Id	Description	level1	level2	level3	cwe	Comment
V2.3.1	Verify system generated initial passwords or activation codes SHOULD be securely randomly generated, SHOULD be at least 6 characters long, and MAY contain letters and numbers, and expire after a short period of time. These initial secrets must not be permitted to become the long term password.	✓	✓	✓	330	Relies on the cloud provider security
V2.3.2	Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens.		✓	✓	308	Relies on the cloud provider security
V2.3.3	Verify that renewal instructions are sent with sufficient time to renew time bound authenticators.		✓	✓	287	Relies on the cloud provider security

Credential Storage

Id	Description	level2	level3	cwe	Comment
V2.4.1	Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash. (C6)	✓	✓	916	Relies on the cloud provider security
V2.4.2	Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored. (C6)	✓	✓	916	Relies on the cloud provider security
V2.4.3	Verify that if PBKDF2 is used, the iteration count SHOULD be as large as verification server performance will allow, typically at least 100,000 iterations. (C6)	✓	✓	916	Relies on the cloud provider security
V2.4.4	Verify that if bcrypt is used, the work factor SHOULD be as large as verification server performance will allow, with a minimum of 10. (C6)	✓	✓	916	Relies on the cloud provider security
V2.4.5	Verify that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A. The secret salt value SHALL be stored separately from the hashed passwords (e.g., in a specialized device like a hardware security module).	✓	✓	916	Relies on the cloud provider security

Credential Recovery

Id	Description	level1	level2	level3	cwe	Comment
V2.5.1	Verify that a system generated initial activation or recovery secret is not sent in clear text to the user. (C6)	✓	✓	✓	640	Relies on the cloud provider security
V2.5.2	Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.	✓	✓	✓	640	Relies on the cloud provider security
V2.5.3	Verify password credential recovery does not reveal the current password in any way. (C6)	✓	✓	✓	640	Relies on the cloud provider security
V2.5.4	Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").	✓	✓	✓	16	Relies on the cloud provider security
V2.5.5	Verify that if an authentication factor is changed or replaced, that the user is notified of this event.	✓	✓	✓	304	Relies on the cloud provider security
V2.5.6	Verify forgotten password, and other recovery paths use a secure recovery mechanism, such as time-based OTP (TOTP) or other soft token, mobile push, or another offline recovery mechanism. (C6)	✓	✓	✓	640	Relies on the cloud provider security
V2.5.7	Verify that if OTP or multi-factor authentication factors are lost, that evidence of identity proofing is performed at the same level as during enrollment.		✓	✓	308	Relies on the cloud provider security

Look-up Secret Verifier

Id	Description	level2	level3	cwe
V2.6.1	Verify that lookup secrets can be used only once.	✓	✓	308
V2.6.2	Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and random 32-bit salt and hashed with an approved one-way hash.	✓	✓	330
V2.6.3	Verify that lookup secrets are resistant to offline attacks, such as predictable values.	✓	✓	310

Out of Band Verifier

Id	Description	level2	level3	cwe
V2.6.1	Verify that lookup secrets can be used only once.	✓	✓	308
V2.6.2	Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, salted with a unique and random 32-bit salt and hashed with an approved one-way hash.	✓	✓	330
V2.6.3	Verify that lookup secrets are resistant to offline attacks, such as predictable values.	✓	✓	310

One Time Verifier

Id	Description	level1	level2	level3	cwe
V2.8.1	Verify that time-based OTPs have a defined lifetime before expiring.	✓	✓	✓	613
V2.8.2	Verify that symmetric keys used to verify submitted OTPs are highly protected, such as by using a hardware security module or secure operating system based key storage.		✓	✓	320
V2.8.3	Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.		✓	✓	326
V2.8.4	Verify that time-based OTP can be used only once within the validity period.		✓	✓	287
V2.8.5	Verify that if a time-based multi-factor OTP token is re-used during the validity period, it is logged and rejected with secure notifications being sent to the holder of the device.		✓	✓	287
V2.8.6	Verify physical single-factor OTP generator can be revoked in case of theft or other loss. Ensure that revocation is immediately effective across logged in sessions, regardless of location.		✓	✓	613
V2.8.7	Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.		o	✓	308

Cryptographic Verifier

Id	Description	level2	level3	cwe
V2.9.1	Verify that cryptographic keys used in verification are stored securely and protected against disclosure, such as using a Trusted Platform Module (TPM) or Hardware Security Module (HSM), or an OS service that can use this secure storage.	✓	✓	320
V2.9.2	Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.	✓	✓	330
V2.9.3	Verify that approved cryptographic algorithms are used in the generation, seeding, and verification.	✓	✓	327

Service Authentication

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V2.10.1	Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.	OS assisted	HSM	287	Yes	Yes	use of rotating secrets
V2.10.2	Verify that if passwords are required for service authentication, the service account used is not a default credential. (e.g. root/root or admin/admin are default in some services during installation).	OS assisted	HSM	255	Yes	Yes
V2.10.3	Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.	OS assisted	HSM	522			Relies on the cloud provider security
V2.10.4	Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.	OS assisted	HSM	798	Yes	Yes

Session Management

Fundamental Session Management Security

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V3.1.1	Verify the application never reveals session tokens in URL parameters.	✓	✓	✓	598	Yes	Yes

Session Binding

Id	Description	level1	level2	level3	cwe	Comment
V3.2.1	Verify the application generates a new session token on user authentication. (C6)	✓	✓	✓	384	No sessions used
V3.2.2	Verify that session tokens possess at least 64 bits of entropy. (C6)	✓	✓	✓	331	No sessions used
V3.2.3	Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.	✓	✓	✓	539	No sessions used
V3.2.4	Verify that session tokens are generated using approved cryptographic algorithms. (C6)		✓	✓	331	No sessions used

Session Termination

Id	Description	level1	level2	level3	cwe	Comment
V3.3.1	Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties. (C6)	✓	✓	✓	613	No sessions used
V3.3.2	If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period. (C6)	30 days	12 hours or 30 minutes of inactivity, 2FA optional	12 hours or 15 minutes of inactivity, with 2FA	613	No sessions used
V3.3.3	Verify that the application gives the option to terminate all other active sessions after a successful password change (including change via password reset/recovery), and that this is effective across the application, federated login (if present), and any relying parties.		✓	✓	613	No sessions used
V3.3.4	Verify that users are able to view and (having re-entered login credentials) log out of any or all currently active sessions and devices.		✓	✓	613	No sessions used

Id	Description	level1	level2	level3	cwe	Comment
V3.4.1	Verify that cookie-based session tokens have the 'Secure' attribute set. (C6)	✓	✓	✓	614	No cookies used
V3.4.2	Verify that cookie-based session tokens have the 'HttpOnly' attribute set. (C6)	✓	✓	✓	1004	No cookies used
V3.4.3	Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks. (C6)	✓	✓	✓	1275	No cookies used
V3.4.4	Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie.	✓	✓	✓	16	No cookies used
V3.4.5	Verify that if the application is published under a domain name with other applications that set or use session cookies that might disclose the session cookies, set the path attribute in cookie-based session tokens using the most precise path possible. (C6)	✓	✓	✓	16	No cookies used

Token-based Session Management

Id	Description	level2	level3	cwe	Comment
V3.5.1	Verify the application allows users to revoke OAuth tokens that form trust relationships with linked applications.	✓	✓	290	No sessions used
V3.5.2	Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.	✓	✓	798	No sessions used
V3.5.3	Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.	✓	✓	345	No sessions used

Federated Re-authentication

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V3.6.1	Verify that Relying Parties (RPs) specify the maximum authentication time to Credential Service Providers (CSPs) and that CSPs re-authenticate the user if they haven't used a session within that period.			✓	613			No sessions used
V3.6.2	Verify that Credential Service Providers (CSPs) inform Relying Parties (RPs) of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.			✓	613			No sessions used

Defenses Against Session Management Exploits

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V3.7.1	Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.	✓	✓	✓	306			No sessions used

Access Control

General Access Control Design

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V4.1.1	Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.	✓	✓	✓	602	Yes	Yes	API validates access on every user facing endpoint
V4.1.2	Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.	✓	✓	✓	639	Yes	Yes
V4.1.3	Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. (C7)	✓	✓	✓	285	Yes	Yes	Kamea provides permissions with a thin granularity. But it is up to the users to configure it properly
V4.1.5	Verify that access controls fail securely including when an exception occurs. (C10)	✓	✓	✓	285	Yes	Yes	Ends up in 401 or 403 error codes

Operation Level Access Control

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V4.2.1	Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.	✓	✓	✓	639	Yes	Yes
V4.2.2	Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.	✓	✓	✓	352	?	?

Other Access Control Considerations

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V4.3.1	Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.	✓	✓	✓	419			Relies on the cloud provider security
V4.3.2	Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.	✓	✓	✓	548	Yes	Yes	No access to file systems
V4.3.3	Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.		✓	✓	732			Too vague

Validation, Sanitization and Encoding

Input Validation

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V5.1.1	Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).	✓	✓	✓	235	Yes	No	Pentest required
V5.1.2	Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar. (C5)	✓	✓	✓	915	Yes	No	Pentest required
V5.1.3	Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists). (C5)	✓	✓	✓	20	Yes	No	N/A
V5.1.4	Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). (C5)	✓	✓	✓	20	Yes	Yes
V5.1.5	Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.	✓	✓	✓	601	Yes	Yes	No links to external systems

Sanitization and Sandboxing

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V5.2.1	Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. (C5)	✓	✓	✓	116	Yes	Yes	Relies on Angular sandboxing
V5.2.2	Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.	✓	✓	✓	138	Yes	No
V5.2.3	Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.	✓	✓	✓	147	No		no mail system
V5.2.4	Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.	✓	✓	✓	95	Yes	Yes	No call to eval() or other code execution functions
V5.2.5	Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.	✓	✓	✓	94	Yes	Yes	Relies on Angular sandboxing
V5.2.6	Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.	✓	✓	✓	918	Yes	No
V5.2.7	Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.	✓	✓	✓	159	Yes ?	No
V5.2.8	Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.	✓	✓	✓	94	No

Output Encoding and Injection Prevention

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V5.3.1	Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). (C4)	✓	✓	✓	116	?
V5.3.2	Verify that output encoding preserves the user's chosen character set and locale, such that any Unicode character point is valid and safely handled. (C4)	✓	✓	✓	176			Pentest required
V5.3.3	Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS. (C4)	✓	✓	✓	79			Pentest required
V5.3.4	Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks. (C3)	✓	✓	✓	89	Yes	Yes	Only using parameterized queries
V5.3.5	Verify that where parameterized or safer mechanisms are not present, context-specific output encoding is used to protect against injection attacks, such as the use of SQL escaping to protect against SQL injection. (C3, C4)	✓	✓	✓	89	No		Only using parameterized queries
V5.3.6	Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation. (C4)	✓	✓	✓	830			Pentest required
V5.3.7	Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. (C4)	✓	✓	✓	90	?		Not using LDAP
V5.3.8	Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding. (C4)	✓	✓	✓	78			Pentest required
V5.3.9	Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.	✓	✓	✓	829			Pentest required
V5.3.10	Verify that the application protects against XPath injection or XML injection attacks. (C4)	✓	✓	✓	643			Pentest required

Memory, String, and Unmanaged Code

Id	Description	level2	level3	cwe	Comment
V5.4.1	Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.	✓	✓	120	Pentest required
V5.4.2	Verify that format strings do not take potentially hostile input, and are constant.	✓	✓	134	Pentest required
V5.4.3	Verify that sign, range, and input validation techniques are used to prevent integer overflows.	✓	✓	190	Pentest required

Deserialization Prevention

Id	Description	level1	level2	level3	cwe	Comment
V5.5.1	Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering. (C5)	✓	✓	✓	502
V5.5.2	Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.	✓	✓	✓	611
V5.5.3	Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).	✓	✓	✓	502
V5.5.4	Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.	✓	✓	✓	95	Done by the framework

Stored Cryptography

Data Classification

Id	Description	level2	level3	cwe	Relevant for Kamea ?
V6.1.1	Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.	✓	✓	311	No
V6.1.2	Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymized research records.	✓	✓	311	No
V6.1.3	Verify that regulated financial data is stored encrypted while at rest, such as financial accounts, defaults or credit history, tax records, pay history, beneficiaries, or de-anonymized market or research records.	✓	✓	311	No

Algorithms

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Comment
V6.2.1	Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.	✓	✓	✓	310	No
V6.2.2	Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. (C8)		✓	✓	327		Only use well known cryptographic libs
V6.2.3	Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.		✓	✓	326	?	?
V6.2.4	Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. (C8)		✓	✓	326		?
V6.2.5	Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.		✓	✓	326		Handled by the libs
V6.2.6	Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.		✓	✓	326		?
V6.2.7	Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.			✓	326		?
V6.2.8	Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.			✓	385		Handled by the libs

Random Values

Id	Description	level2	level3	cwe	Comment
V6.3.1	Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker.	✓	✓	338	Handled by the libs
V6.3.2	Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable.	✓	✓	338	Handled by the libs
V6.3.3	Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances.		✓	338	Handled by the libs

Secret Management

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V6.4.1	Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy secrets. (C8)		✓	✓	798			Several Azure resources hold secrets. Kamea relies on Azure to enforce their security.
V6.4.2	Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations. (C8)		✓	✓	320	Yes	Yes

Error Handling and Logging

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?
V7.1.1	Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form. (C9, C10)	✓	✓	✓	532	Yes	Yes
V7.1.2	Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy. (C9)	✓	✓	✓	532	No
V7.1.3	Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures. (C5, C7)		✓	✓	778	?
V7.1.4	Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens. (C9)		✓	✓	778	?

Log Content

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V7.2.1	Verify that all authentication decisions are logged, without storing sensitive session tokens or passwords. This should include requests with relevant metadata needed for security investigations.		✓	✓	778			Relies on the cloud provider security
V7.2.2	Verify that all access control decisions can be logged and all failed decisions are logged. This should include requests with relevant metadata needed for security investigations.		✓	✓	285			Relies on the cloud provider security

Log Processing

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V7.3.1	Verify that all logging components appropriately encode data to prevent log injection. (C9)	✓	✓	117	?
V7.3.3	Verify that security logs are protected from unauthorized access and modification. (C9)	✓	✓	200	?
V7.3.4	Verify that time sources are synchronized to the correct time and time zone. Strongly consider logging only in UTC if systems are global to assist with post-incident forensic analysis. (C9)	✓	✓		Yes	No	Logs don't have a consistent time source

Error Handling

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V7.4.1	Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate. (C10)	✓	✓	✓	210	?		What is an unexpected or security sensitive error ?
V7.4.2	Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions. (C10)		✓	✓	544	Yes	Yes
V7.4.3	Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. (C10)		✓	✓	431	Yes	Yes	Returns a 500 Internal Server Error

Data Protection

General Data Protection

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V8.1.1	Verify the application protects sensitive data from being cached in server components such as load balancers and application caches.	✓	✓	524	Yes	Yes	No cache used
V8.1.2	Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.	✓	✓	524	No
V8.1.3	Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.	✓	✓	233	Yes	Yes	Only required parameters are used
V8.1.4	Verify the application can detect and alert on abnormal numbers of requests, such as by IP, user, total per hour or day, or whatever makes sense for the application.	✓	✓	770	Yes	Yes	Rate limiting used when necessary
V8.1.5	Verify that regular backups of important data are performed and that test restoration of data is performed.		✓	19	Yes	No	No backup in place
V8.1.6	Verify that backups are stored securely to prevent data from being stolen or corrupted.		✓	19	No		No backup in place

Client-side Data Protection

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Comment
V8.2.1	Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers.	✓	✓	✓	525	?
V8.2.2	Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.	✓	✓	✓	922		Access token contained in sessionStorage
V8.2.3	Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated.	✓	✓	✓	922	No ?

Sensitive Private Data

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V8.3.1	Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.	✓	✓	✓	319	Yes	Yes	Sensitive data like tokens always in body or headers.
V8.3.2	Verify that users have a method to remove or export their data on demand.	✓	✓	✓	212	Yes	No
V8.3.3	Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.	✓	✓	✓	285	?
V8.3.4	Verify that all sensitive data created and processed by the application has been identified, and ensure that a policy is in place on how to deal with sensitive data. (C8)	✓	✓	✓	200			Too vague
V8.3.5	Verify accessing sensitive data is audited (without logging the sensitive data itself), if the data is collected under relevant data protection directives or where logging of access is required.		✓	✓	532			Too vague
V8.3.6	Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data.		✓	✓	226	?
V8.3.7	Verify that sensitive or private information that is required to be encrypted, is encrypted using approved algorithms that provide both confidentiality and integrity. (C8)		✓	✓	327	?
V8.3.8	Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires.		✓	✓	285	?

Communication

Client Communication Security

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V9.1.1	Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. (C8)	✓	✓	✓	319	Yes	Yes
V9.1.2	Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.	✓	✓	✓	326			Pentest required
V9.1.3	Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option.	✓	✓	✓	326	Yes	No

Server Communication Security

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V9.2.1	Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.	✓	✓	295	?		mTLS is only used to authenticate devices in some cases. Server certificate is always validated by the browser when calling the API
V9.2.2	Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecure or unencrypted protocols.	✓	✓	319	Yes	Yes
V9.2.3	Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.	✓	✓	287	Yes	Yes
V9.2.4	Verify that proper certification revocation, such as Online Certificate Status Protocol (OCSP) Stapling, is enabled and configured.	✓	✓	299	?
V9.2.5	Verify that backend TLS connection failures are logged.		✓	544	?	No

Malicious Code

Code Integrity

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V10.1.1	Verify that a code analysis tool is in use that can detect potentially malicious code, such as time functions, unsafe file operations and network connections.			✓	749	?	No	No such tool in place

Malicious Code Search

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Comment
V10.2.1	Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data.	✓	✓	359	No
V10.2.2	Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.	✓	✓	272	No
V10.2.3	Verify that the application source code and third party libraries do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered.		✓	507		Pentest needed
V10.2.4	Verify that the application source code and third party libraries do not contain time bombs by searching for date and time related functions.		✓	511		Pentest needed
V10.2.5	Verify that the application source code and third party libraries do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs.		✓	511		No salami attack - application is strictly vegan
V10.2.6	Verify that the application source code and third party libraries do not contain Easter eggs or any other potentially unwanted functionality.		✓	507		Easter egg hunt needed

Application Integrity

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V10.3.1	Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.	✓	✓	✓	16	No
V10.3.2	Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.	✓	✓	✓	353	?
V10.3.3	Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.	✓	✓	✓	350	Yes	No	Needs to be documented, CNAME records are used to target resources with predictable names

Business Logic

Business Logic Security

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V11.1.1	Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.	✓	✓	✓	841			Pentest needed
V11.1.2	Verify that the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.	✓	✓	✓	799			Pentest needed
V11.1.3	Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis.	✓	✓	✓	770			Pentest needed
V11.1.4	Verify that the application has anti-automation controls to protect against excessive calls such as mass data exfiltration, business logic requests, file uploads or denial of service attacks.	✓	✓	✓	770	Yes	Depends	Rate limiting in some places
V11.1.5	Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies.	✓	✓	✓	841			Pentest needed
V11.1.6	Verify that the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations.		✓	✓	367			Pentest needed
V11.1.7	Verify that the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt. (C9)		✓	✓	754			Pentest needed
V11.1.8	Verify that the application has configurable alerting when automated attacks or unusual activity is detected.		✓	✓	390	Depends on the customer?

Files and Resources

File Upload

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?
V12.1.1	Verify that the application will not accept large files that could fill up storage or cause a denial of service.	✓	✓	✓	400	No
V12.1.2	Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.		✓	✓	409	No
V12.1.3	Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.		✓	✓	770	No

File Integrity

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V12.2.1	Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.		✓	✓	434	Yes	No	Uploaded images format isn't checked

File Execution

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V12.3.1	Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.	✓	✓	✓	22	Yes	Yes
V12.3.2	Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).	✓	✓	✓	73			Pentest needed
V12.3.3	Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks.	✓	✓	✓	98			Pentest needed
V12.3.4	Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.	✓	✓	✓	641			Pentest needed
V12.3.5	Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.	✓	✓	✓	78			Pentest needed
V12.3.6	Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.		✓	✓	829			Pentest needed

File Storage

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V12.4.1	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.	✓	✓	✓	552	Yes	Yes	User submitted files are stored on a managed Azure Storage account, not on the API server
V12.4.2	Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content.	✓	✓	✓	509	?		Overkill

File Download

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V12.5.1	Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.	✓	✓	✓	552	No		Cannot download file by name.
V12.5.2	Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.	✓	✓	✓	434	?		Only user uploaded file is the tenant logo, which is displayed in the front end

SSRF Protection

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V12.6.1	Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.	✓	✓	✓	918	Yes	No	Overkill

API and Web Service

Generic Web Service Security

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V13.1.1	Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.	✓	✓	✓	116			Pentest needed
V13.1.3	Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.	✓	✓	✓	598			Pentest needed
V13.1.4	Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.		✓	✓	285	Yes	Yes	Authorization checked on all routes by default
V13.1.5	Verify that requests containing unexpected or missing content types are rejected with appropriate headers (HTTP response status 406 Unacceptable or 415 Unsupported Media Type).		✓	✓	434	Yes		Relies on the framework

RESTful Web Service

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V13.2.1	Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.	✓	✓	✓	650	Yes	Yes
V13.2.2	Verify that JSON schema validation is in place and verified before accepting input.	✓	✓	✓	20	Yes	Yes
V13.2.3	Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: double submit cookie pattern, CSRF nonces, or Origin request header checks.	✓	✓	✓	352	No		No cookies
V13.2.5	Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.		✓	✓	436	?
V13.2.6	Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.		✓	✓	345	Yes	Yes	TLS always used, all APIs only accept HTTPS

SOAP Web Service

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V13.3.1	Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.	✓	✓	✓	20	No		No SOAP
V13.3.2	Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.		✓	✓	345	No		No SOAP

GraphQL

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V13.4.1	Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries. For more advanced scenarios, query cost analysis should be used.		✓	✓	770	No		No GraphQL
V13.4.2	Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.		✓	✓	285	No		No GraphQL

Configuration

Build and Deploy

Id	Description	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V14.1.1	Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts.	✓	✓		Yes	Yes
V14.1.2	Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.	✓	✓	120	?
V14.1.3	Verify that server configuration is hardened as per the recommendations of the application server and frameworks in use.	✓	✓	16			Too vague
V14.1.4	Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.	✓	✓		Yes	Yes
V14.1.5	Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.		✓		?

Dependency

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V14.2.1	Verify that all components are up to date, preferably using a dependency checker during build or compile time. (C2)	✓	✓	✓	1026	Yes	No ?	Cannot control dependencies of dependencies
V14.2.2	Verify that all unneeded features, documentation, sample applications and configurations are removed.	✓	✓	✓	1002	Yes	Yes
V14.2.3	Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.	✓	✓	✓	829	?
V14.2.4	Verify that third party components come from pre-defined, trusted and continually maintained repositories. (C2)		✓	✓	829	Yes	Yes	Only pull from official npm store
V14.2.5	Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use. (C2)		✓	✓		Yes	No
V14.2.6	Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application. (C2)		✓	✓	265	?		Overkill ?

Unintended Security Disclosure

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V14.3.2	Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.	✓	✓	✓	497	Yes	Yes
V14.3.3	Verify that the HTTP headers or any part of the HTTP response do not expose detailed version information of system components.	✓	✓	✓	200	Yes	No

HTTP Security Headers

Id	Description	level1	level2	level3	cwe	Comment
V14.4.1	Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.	✓	✓	✓	173	Pentest needed
V14.4.2	Verify that all API responses contain a Content-Disposition: attachment; filename="api.json" header (or other appropriate filename for the content type).	✓	✓	✓	116	Pentest needed
V14.4.3	Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.	✓	✓	✓	1021	Pentest needed
V14.4.4	Verify that all responses contain a X-Content-Type-Options: nosniff header.	✓	✓	✓	116	Pentest needed
V14.4.5	Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; includeSubdomains.	✓	✓	✓	523	Pentest needed
V14.4.6	Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.	✓	✓	✓	116	Pentest needed
V14.4.7	Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.	✓	✓	✓	1021	Pentest needed

HTTP Request Header Validation

Id	Description	level1	level2	level3	cwe	Relevant for Kamea ?	Kamea support ?	Comment
V14.5.1	Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.	✓	✓	✓	749			Pentest needed
V14.5.2	Verify that the supplied Origin header is not used for authentication or access control decisions, as the Origin header can easily be changed by an attacker.	✓	✓	✓	346	Yes	Yes
V14.5.3	Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted domains and subdomains to match against and does not support the "null" origin.	✓	✓	✓	346	Yes	Yes
V14.5.4	Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.		✓	✓	306	No		No header added by any external source

Requirements from Witekio Security Framework

Design

Cryptography

Software Security

Hardware Security

Network Security

Robustness

OWASP ASVS

Architecture, Design and Threat Modeling

Secure Software Development Lifecycle

Authentication Architecture

Access Control Architecture

Input and Output Architecture

Cryptographic Architecture

Errors, Logging and Auditing Architecture

Data Protection and Privacy Architecture

Communications Architecture

Malicious Software Architecture

Business Logic Architecture

Secure File Upload Architecture

Configuration Architecture

Authentication

Password Security

General Authenticator Security

Authenticator Lifecycle

Credential Storage

Credential Recovery

Look-up Secret Verifier

Out of Band Verifier

One Time Verifier

Cryptographic Verifier

Service Authentication

Session Management

Fundamental Session Management Security

Session Binding

Session Termination

Cookie-based Session Management

Token-based Session Management

Federated Re-authentication

Defenses Against Session Management Exploits

Access Control

General Access Control Design

Operation Level Access Control

Other Access Control Considerations

Validation, Sanitization and Encoding

Input Validation

Sanitization and Sandboxing

Output Encoding and Injection Prevention

Memory, String, and Unmanaged Code

Deserialization Prevention

Stored Cryptography

Data Classification

Algorithms

Random Values

Secret Management

Error Handling and Logging

Log Content

Log Processing

Error Handling

Data Protection

General Data Protection

Client-side Data Protection

Sensitive Private Data

Communication

Client Communication Security

Server Communication Security

Malicious Code

Code Integrity

Malicious Code Search

Application Integrity

Business Logic

Business Logic Security

Files and Resources

File Upload

File Integrity

File Execution

File Storage

File Download

SSRF Protection

API and Web Service