ABDEFLMNOPQRSTUVWXYZ
1
chapter_id
chapter_namesection_namereq_idreq_description
automated testing
testing strategy
implemented
(estimated) effort
spent timetest IDnotes (based on an implementation within the SAMMY tool leveraging PHP Symfony 7 and phpunit frameworks)
5
V1
Architecture, Design and Threat Modeling
Secure Software Development Lifecycle
V1.1.4Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.no
6
V1
Architecture, Design and Threat Modeling
Secure Software Development Lifecycle
V1.1.5Verify definition and security analysis of the application's high-level architecture and all connected remote services.no
7
V1
Architecture, Design and Threat Modeling
Secure Software Development Lifecycle
V1.1.6Verify implementation of centralized, simple (economy of design), vetted, secure, and reusable security controls to avoid duplicate, missing, ineffective, or insecure controls.no
10
V1
Architecture, Design and Threat Modeling
Authentication ArchitectureV1.2.2[MODIFIED] Verify that communications between back-end application components, including APIs, middleware and data layers, are authenticated and use individual user accounts.fullintegrationCreate positive and negative test cases to assert that communication between components is properly authenticated.
11
V1
Architecture, Design and Threat Modeling
Authentication ArchitectureV1.2.3[MODIFIED] Verify that the application uses a single vetted user 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.partialintegrationLogging can be fully tested. Making sure that there is a single vetted auth mechanism is an architectural review.
12
V1
Architecture, Design and Threat Modeling
Authentication ArchitectureV1.2.4[MODIFIED, SPLIT TO 2.2.11] Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication strength which should be consistently enforced across them.no
13
V1
Architecture, Design and Threat Modeling
Authentication ArchitectureV1.2.5[ADDED] Verify that a list of context specific words are documented in order to prevent their use in passwords.fullunitWrite tests to ensure that passwords with a collection of context-specific words are not allowed to be selected.
17
V1
Architecture, Design and Threat Modeling
Access Control Architecture
V1.4.4Verify 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.partialintegrationIn general this is an architectural check and code review check to ensure that e.g., all controllers are leveraging authorization. It is possible to create unit/integration tests to ensure that all API endpoints feature IS_GRANTED attribute. Also write a negative test per endpoint to ensure that non-authenticated requests are rejected with the appropriate response.
18
V1
Architecture, Design and Threat Modeling
Access Control Architecture
V1.4.5[GRAMMAR] Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature or data item rather than just their role. Permissions should still be allocated using roles.fullintegrationWrite integration tests to assert that all access control decisions are based on attribute or feature-based access control. SAST could be leveraged to flag all endpoints that don't have an IS_GRANTED in the attributes.
19
V1
Architecture, Design and Threat Modeling
Input and Output Architecture
V1.5.1[MODIFIED, LEVEL L2 > L1] Verify that input and output requirements clearly define how to handle and process data based on type and content.no
23
V1
Architecture, Design and Threat Modeling
Cryptographic ArchitectureV1.6.1Verify 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.no
24
V1
Architecture, Design and Threat Modeling
Cryptographic ArchitectureV1.6.2Verify that consumers of cryptographic services protect key material and other secrets by using key vaults or API based alternatives.no
25
V1
Architecture, Design and Threat Modeling
Cryptographic ArchitectureV1.6.3Verify that all keys and passwords are replaceable and are part of a well-defined process to re-encrypt sensitive data.no
26
V1
Architecture, Design and Threat Modeling
Cryptographic ArchitectureV1.6.4[GRAMMAR] 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.no
29
V1
Architecture, Design and Threat Modeling
Errors, Logging and Auditing Architecture
V1.7.3[ADDED] Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled and how long logs are kept for.no
30
V1
Architecture, Design and Threat Modeling
Data Protection and Privacy Architecture
V1.8.1[MODIFIED, MERGED FROM 8.3.4, LEVEL L2 > L1] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data.no
31
V1
Architecture, Design and Threat Modeling
Data Protection and Privacy Architecture
V1.8.2[MODIFIED, SPLIT TO 8.1.9] Verify that all protection levels have a documented set of protection requirements. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, how the data should be logged, access controls around sensitive data in logs, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.partialunitdata retention policy can be verified automatically by making sure that data is timely destroyed or anonymized.
35
V1
Architecture, Design and Threat Modeling
Business Logic Architecture
V1.11.1Verify the definition and documentation of all application components in terms of the business or security functions they provide.no
36
V1
Architecture, Design and Threat Modeling
Business Logic Architecture
V1.11.2[MODIFIED] Verify that all application flows including authentication, session management and access control, maintain a consistent application and user state to prevent race conditions and business logic flaws.no
37
V1
Architecture, Design and Threat Modeling
Business Logic Architecture
V1.11.3Verify 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.no
38
V1
Architecture, Design and Threat Modeling
Business Logic Architecture
V1.11.4[ADDED] Verify that expectations for business logic limits and validations are clearly documented including both per-user and also globally across the application.fullintegrationanything related to constraints and limits can be automatically tested. I am just somewhat unsure whether this should get a full or partial label.
41
V1
Architecture, Design and Threat Modeling
Configuration ArchitectureV1.14.1[MODIFIED] Verify the segregation of back-end components of differing trust levels through well-defined security controls, firewall rules, API gateways, reverse proxies, cloud-based security groups, or similar mechanisms.no
45
V1
Architecture, Design and Threat Modeling
Configuration ArchitectureV1.14.5[MODIFIED] Verify that application deployments adequately sandbox 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.no
47
V1
Architecture, Design and Threat Modeling
Configuration ArchitectureV1.14.7[MODIFIED, MOVED FROM 1.2.1] Verify the use of unique or special low-privilege operating system accounts for all back-end application components, services, and servers.no
48
V1
Architecture, Design and Threat Modeling
Configuration ArchitectureV1.14.8[ADDED] Verify that the application is able to discern and utilizes the user's true IP address to provide for sensitive functions, including rate limiting and logging.no
49
V2AuthenticationPassword SecurityV2.1.1[MODIFIED] Verify that user set passwords are at least 8 characters in length.fullunit
50
V2AuthenticationPassword SecurityV2.1.2[MODIFIED, SPLIT TO 2.4.6] Verify that passwords of at least 64 characters are permitted.fullunit
51
V2AuthenticationPassword SecurityV2.1.3[MODIFIED] Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation.fullunit
52
V2AuthenticationPassword SecurityV2.1.4Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.fullunit
53
V2AuthenticationPassword SecurityV2.1.5Verify users can change their password.fullintegration
54
V2AuthenticationPassword SecurityV2.1.6Verify that password change functionality requires the user's current and new password.fullunit
55
V2AuthenticationPassword SecurityV2.1.7[MODIFIED, SPLIT TO 2.1.14] Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords.fullintegration
57
V2AuthenticationPassword SecurityV2.1.9Verify 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.fullunit
58
V2AuthenticationPassword SecurityV2.1.10[MODIFIED, SPLIT TO 2.1.13, LEVEL L1 > L2] Verify that the application does not require periodic credential rotation.no
59
V2AuthenticationPassword SecurityV2.1.11Verify that "paste" functionality, browser password helpers, and external password managers are permitted.fullacceptance
60
V2AuthenticationPassword SecurityV2.1.12[MODIFIED] Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password.fullintegration
61
V2AuthenticationPassword SecurityV2.1.13[ADDED, SPLIT FROM 2.1.10, LEVEL L1 > L2] Verify that the application does not keep a password history.noasserting something that isn't there
62
V2AuthenticationPassword SecurityV2.1.14[ADDED, SPLIT FROM 2.1.7, LEVEL L1 > L3] Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords.fullintegrationunit could also be used here, but integration is better
63
V2AuthenticationPassword SecurityV2.1.15[ADDED] Verify that the documented list of context specific words is used to prevent easy to guess passwords being created.fullunit
64
V2Authentication
General Authenticator Security
V2.2.1[MODIFIED] 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. More than 5 failed authentication attempts per hour for a single account should trigger some sort of reaction or alert.fullintegrationassert the use of captcha and rate limiters where necessary.
65
V2Authentication
General Authenticator Security
V2.2.2[MODIFIED, SPLIT TO 2.2.12] Verify that restricted authenticators (those using PSTN to deliver OTPs via phone or SMS) are offered only when alternate stronger methods are also offered and when the service provides information on their security risks to users.fullintegrationthis test is somewhat silly as we will be asserting that other than SMS authenticators are offered. if an SMS authenticator is offered it should come with a warning.
66
V2Authentication
General Authenticator Security
V2.2.3[MODIFIED, SPLIT TO 2.2.10] Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address.fullintegrationassert a mailing is sent on changing credentials
67
V2Authentication
General Authenticator Security
V2.2.4[MODIFIED, SPLIT TO 2.2.9] Verify that a hardware-based authenticator and an authenticator that provides verifier impersonation resistance against phishing attacks (such as WebAuthn) are used.nohardware could be mocked in test cases, but i'm flagging this as a no for now.
68
V2Authentication
General Authenticator Security
V2.2.5Verify that where a Credential Service Provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.fullintegrationassert that application to CSP communication is mutually TLS authenticated
69
V2Authentication
General Authenticator Security
V2.2.6Verify replay resistance through the mandated use of One-time Passwords (OTP) devices, cryptographic authenticators, or lookup codes.fullintegrationassert that OTP cannot be reused within the single time window.
70
V2Authentication
General Authenticator Security
V2.2.7Verify 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.partialintegrationthe first part (if it's an OTP) boils down to asserting the implemented OTP solution. Assering user-initiated action on a hardware key might be trickier, hence partial.
71
V2Authentication
General Authenticator Security
V2.2.8[ADDED] Verify that valid users cannot be deduced from failed authentication challenges, such as based on error messages, HTTP response codes, or different response times. Registration and forgot password functionality should also have this protection.fullintegrationassert that the time required to login with correct and incorrect accounts is the same. assert that password reset functionalty as well as the registration page shows the same message for existing and non-existing users. i am really unsure what to do with registration though.
72
V2Authentication
General Authenticator Security
V2.2.9[ADDED, SPLIT FROM 2.2.4] Verify that multi-factor authentication is required, that is, the application uses either a multi-factor authenticator or a combination of single-factor authenticators.fullintegrationassert that after a successful login the user is redirected to the MFA page.
73
V2Authentication
General Authenticator Security
V2.2.10[ADDED, SPLIT FROM 2.2.3] Verify that users are notified of suspicious authentication attempts. Suspicious authentication attempts may include successful or unsuccessful authentication from an unusual location or client, partially successful authentication with only one of multiple factors, successful or unsuccessful authentication after a long period of inactivity or successful authentication after several unsuccessful attempts.fullintegrationassert that the user is notified upon suspicious successful / unsuccessful auth attempts.
74
V2Authentication
General Authenticator Security
V2.2.11[ADDED, SPLIT FROM 1.2.4] Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently.no
75
V2Authentication
General Authenticator Security
V2.2.12[ADDED, SPLIT FROM 2.2.2] Verify that email is not used as either a single-factor or multi-factor authentication mechanism.nonegative assertion (making sure something isn't there). This should be handled at RRR level by the QA.
76
V2AuthenticationAuthenticator LifecycleV2.3.1[MODIFIED] Verify system generated initial passwords or activation codes are securely randomly generated, at least 6 characters long, may contain letters and numbers, expire after a short period of time, and are single-use. These initial secrets must not be permitted to become the long term password.fullunitassert the initial access token has sufficient entropy, at least 6 chars long, contains letters and numbers and expires after a short period of time and it is wiped after use.
77
V2AuthenticationAuthenticator LifecycleV2.3.2Verify that enrollment and use of user-provided authentication devices are supported, such as a U2F or FIDO tokens.fullintegrationwrite a test case to assert that the positive use case of enrolling U2F or FIDO token device works properly.
78
V2AuthenticationAuthenticator LifecycleV2.3.3[MODIFIED] Verify that automated reminders are configured and acted on to ensure that renewal instructions for time-bound authenticators are sent with enough time to be carried out before the old authenticator expires.fullintegrationassert that the notification is sent on pre-defined period / time interval before the expiration of a time-bound authenticator
79
V2AuthenticationAuthenticator LifecycleV2.3.4[ADDED] System administrators should not be able to change or choose any user's password, but rather only be able to initiate the password reset process for the user.no"negative assertion"
80
V2AuthenticationCredential StorageV2.4.1[MODIFIED, MERGED FROM 2.4.3, 2.4.4] Verify that user passwords are stored using an approved password hashing algorithm that is securely configured according to current guidance.fullunitassert that passwords are hashed using bcrypt with the appropriate configuration
85
V2AuthenticationCredential StorageV2.4.6[ADDED, SPLIT FROM 2.1.2] Verify that the application is protected against a denial of service attack caused by processing an overly long password.fullunitassert that application rejects an overly long password
87
V2AuthenticationCredential RecoveryV2.5.2Verify password hints or knowledge-based authentication (so-called "secret questions") are not present.no"negative assertion"
89
V2AuthenticationCredential RecoveryV2.5.4[MODIFIED] Verify that default user accounts (e.g. "root", "admin", or "sa") are not present in the application or are disabled.no
91
V2AuthenticationCredential RecoveryV2.5.6Verify 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.fullintegrationassert that forgot password feature creates and sends a time-based TOTP to the user.
92
V2AuthenticationCredential RecoveryV2.5.7[LEVEL L2 > L1] 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.no
93
V2AuthenticationLookup Secret VerifierV2.6.1Verify that lookup secrets can be used only once.fullintegrationassert that MFA backup codes can only be used once
94
V2AuthenticationLookup Secret VerifierV2.6.2[MODIFIED, SPLIT TO 2.6.4] Verify that lookup secrets stored at the back-end with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more.fullunitassert that backup codes have sufficient entropy and are stored using a hash.
95
V2AuthenticationLookup Secret VerifierV2.6.3[MODIFIED] Verify that lookup secrets are generated using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) to avoid predictable values.fullintegrationassert that the secret generator leverages a CSPRNG function offered by the technology.
96
V2AuthenticationLookup Secret VerifierV2.6.4[ADDED, SPLIT FROM 2.6.2] Verify that lookup secrets have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient).fullunitassert that enropy is 20 bits
97
V2AuthenticationOut-of-Band VerifierV2.7.1[GRAMMAR] Verify that cleartext out-of-band (NIST "restricted") authenticators, such as SMS or PSTN, are not offered by default, and stronger alternatives such as push notifications are offered first.no"negative assertion"
98
V2AuthenticationOut-of-Band VerifierV2.7.2[MODIFIED] Verify that the out-of-band verifier expires out-of-band authentication requests, codes, or tokens within 10 minutes.fullunitassert that the codes/tokens expire after 10 minutes
99
V2AuthenticationOut-of-Band VerifierV2.7.3[GRAMMAR] Verify that the out-of-band verifier authentication requests, codes, or tokens are only usable once, and only for the original authentication request.fullintegrationassert that the requests/codes/tokens cannot be used more than once
100
V2AuthenticationOut-of-Band VerifierV2.7.4[GRAMMAR] Verify that the out-of-band authenticator and verifier communicates over a secure independent channel.no
101
V2AuthenticationOut-of-Band VerifierV2.7.5[GRAMMAR] Verify that the out-of-band verifier retains only a hashed version of the authentication code.fullunitassert that the OOB verifier hashes the auth code
102
V2AuthenticationOut-of-Band VerifierV2.7.6[MODIFIED] Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient).fullunitassert that CSPRNG function is used to generate the initial auth code and assert the minimum enthropy for the initial auth code
103
V2AuthenticationOut-of-Band VerifierV2.7.7[ADDED] Verify that the initial authentication code is protected against brute force attacks by using either rate limiting or a code with at least 64 bits of entropy.fullintegrationassert that the endpoint that hosts the initial auth code is protected against brute force attacks or that the code has at least 64 bits of entropy
104
V2AuthenticationOne-Time VerifierV2.8.1Verify that time-based OTPs have a defined lifetime before expiring.fullunitassert that MFA OTP expires after 30 sec
105
V2AuthenticationOne-Time VerifierV2.8.2Verify 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.fullunitassert that MFA key is stored encrypted in the DB
106
V2AuthenticationOne-Time VerifierV2.8.3Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs.fullintegrationassert that HMAC-SHA256 is used to generate and verify the OTPs
107
V2AuthenticationOne-Time VerifierV2.8.4Verify that time-based OTP can be used only once within the validity period.fullintegrationassert that the same MFA token cannot be reused within 30 seconds
108
V2AuthenticationOne-Time VerifierV2.8.5Verify 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.fullintegrationassert that a reuse of OTP within the validity period triggers a notification to the user
109
V2AuthenticationOne-Time VerifierV2.8.6Verify 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.fullintegrationassert the functionality for revoking physical OTP generator
110
V2AuthenticationOne-Time VerifierV2.8.7[MODIFIED, LEVEL L2 > L3] Verify that biometric authenticators are only used as secondary factors together with either something you have or something you know.no
111
V2AuthenticationOne-Time VerifierV2.8.8[ADDED] Ensure that generation of the time-based multi-factor OTP token is based on the server's system time and not the client's machine.noThe OTP solution I have in mind never allows this so I am unsure whether it's possible to assert this.
112
V2AuthenticationCryptographic VerifierV2.9.1Verify 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.noOutside my area of expertise, but feels like a no
113
V2AuthenticationCryptographic VerifierV2.9.2Verify that the challenge nonce is at least 64 bits in length, and statistically unique or unique over the lifetime of the cryptographic device.noOutside my area of expertise, but feels like a no
114
V2AuthenticationCryptographic VerifierV2.9.3[MODIFIED] Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of the cryptographic keys.noOutside my area of expertise, but feels like a no
115
V2AuthenticationService AuthenticationV2.10.1Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys or shared accounts with privileged access.no"negative assertion"
116
V2AuthenticationService AuthenticationV2.10.2[GRAMMAR] Verify that if a credential has to be used for service authentication, the credential being used by the consumer is not a default credential (e.g. root/root or admin/admin are default in some services during installation).no
118
V2AuthenticationService AuthenticationV2.10.4[GRAMMAR] 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.no
120
V3
Session Management
Fundamental Session Management Security
V3.1.2[ADDED] Verify that the application performs all session token verification using a trusted, back-end service.no
121
V3
Session Management
Fundamental Session Management Security
V3.1.3[MODIFIED, MOVED FROM 3.5.2, LEVEL L2 > L1] Verify that the application uses either cryptographically signed or opaque tokens for session management. Static API secrets and keys should be avoided.no
122
V3
Session Management
Session BindingV3.2.1[MODIFIED] Verify the application generates a new session token on user authentication, including re-authentication, and terminates the current session token.fullintegrationassert that the session ID changes after logging in
123
V3
Session Management
Session BindingV3.2.2[MODIFIED] Verify that opaque session tokens possess at least 128 bits of entropy.fullunitassert the entropy of the session ID
125
V3
Session Management
Session BindingV3.2.4[MODIFIED] Verify that opaque session tokens are generated using a secure random function.nothis is typically provided by the framework and they are securely generated by design (or at least should be)
126
V3
Session Management
Session BindingV3.2.5[ADDED] Verify that creating a session for the application requires the user's consent and that the application is protected against a CSRF-style attack where a new application session for the user is created via SSO without user interaction.noTODO - need to find out more information about this one
128
V3
Session Management
Session TimeoutV3.3.2[MODIFIED, SPLIT TO 3.3.5] Verify that there is an absolute maximum session lifetime such that re-authentication is required at least every 30 days for L1 applications or every 12 hours for L2 and L3 applications.fullintegrationassert session lifetime as mandated by the levels.
131
V3
Session Management
Session TimeoutV3.3.5[ADDED, SPLIT FROM 3.3.2] Verify that re-authentication is required after 30 minutes of inactivity for L2 applications or after 15 minutes of inactivity for L3 applications.fullintegrationassert session lifetime as mandated by the levels
132
V3
Session Management
Cookie-based Session Management
V3.4.1Verify that cookie-based session tokens have the 'Secure' attribute set.fullintegrationassert logged in user cookie flags
133
V3
Session Management
Cookie-based Session Management
V3.4.2[MODIFIED] Verify that cookie-based session tokens are not readable by client-side scripts. The session token cookie should have the 'HttpOnly' attribute set and the session token value should only be transferred to the client via the Set-Cookie header.fullintegrationassert logged in user cookie flags
134
V3
Session Management
Cookie-based Session Management
V3.4.3Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.fullintegrationassert logged in user cookie flags
135
V3
Session Management
Cookie-based Session Management
V3.4.4Verify that cookie-based session tokens use the "__Host-" prefix so cookies are only sent to the host that initially set the cookie.fullintegrationassert logged in user cookie flags
137
V3
Session Management
Token-based Session Management
V3.5.1[GRAMMAR] Verify that the application allows users to revoke OAuth tokens that form trust relationships with linked applications.fullintegrationassert oauth token revokation feature works as expected