OpenClearOpenClear measured against the OWASP Application Security Verification Standard 5.0, at Level 2, and Level 3 in V6–V11 and V16 (ADR 0001). The assessment was OpenClear's own; an independent penetration test is planned. It isn't legal advice (Compliance).
Evidence names the code or document that meets the requirement, and the tests that prove it (each test is marked with the requirement it proves, so this page can't name a test that doesn't exist). Service provider's (CUEC) means it depends on whoever runs the installation (CUECs).
283 requirements in scope (62 more are above the target level or don't apply to OpenClear at all, such as WebRTC):
| Status | Requirements |
|---|---|
| Met | 214 |
| Partly | 8 |
| Not met | 5 |
| Service provider's (CUEC) | 15 |
| Not applicable | 41 |
Requirements not fully met are planned for 1.24 and 1.25, or recorded with their reason (OWASP_PLAN.md).
V1 Encoding and Sanitization
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V1.1.1 Verify that input is decoded or unescaped into a canonical form only once, it is only decoded when encoded data in that form is expected, and that this is do… | 2 | Met | src/openclear/web/templates.py |
|
| V1.1.2 Verify that the application performs output encoding and escaping either as a final step before being used by the interpreter for which it is intended or by… | 2 | Met | src/openclear/web/templates.py |
|
| V1.2.1 Verify that output encoding for an HTTP response, HTML document, or XML document is relevant for the context required, such as encoding the relevant characte… | 1 | Met | src/openclear/web/templates.py, src/openclear/web/security_headers.py |
Jinja autoescape, URL quoting and tojson; a CSP with a nonce. |
| V1.2.2 Verify that when dynamically building URLs, untrusted data is encoded according to its context (e.g., URL encoding or base64url encoding for query or path pa… | 1 | Met | src/openclear/web/templates.py, src/openclear/web/security_headers.py |
Jinja autoescape, URL quoting and tojson; a CSP with a nonce. |
| V1.2.3 Verify that output encoding or escaping is used when dynamically building JavaScript content (including JSON), to avoid changing the message or document stru… | 1 | Met | src/openclear/web/templates.py, src/openclear/web/security_headers.py |
Jinja autoescape, URL quoting and tojson; a CSP with a nonce. |
| V1.2.4 Verify that data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) use parameterized queries, ORMs, entity frameworks, or are otherwise protected… | 1 | Met | src/openclear/services/, src/openclear/repositories/ |
|
| V1.2.5 Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line… | 1 | Met | src/openclear/services/, src/openclear/repositories/ |
|
| V1.2.6 Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented. | 2 | Not applicable | — | No LDAP. |
| V1.2.7 Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries. | 2 | Not applicable | — | No XPath. |
| V1.2.8 Verify that LaTeX processors are configured securely (such as not using the "--shell-escape" flag) and an allowlist of commands is used to prevent LaTeX inje… | 2 | Not applicable | — | No LaTeX. |
| V1.2.9 Verify that the application escapes special characters in regular expressions (typically using a backslash) to prevent them from being misinterpreted as meta… | 2 | Met | src/openclear/services/, src/openclear/repositories/ |
|
| V1.3.1 Verify that all untrusted HTML input from WYSIWYG editors or similar is sanitized using a well-known and secure HTML sanitization library or framework feature. | 1 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.2 Verify that the application avoids the use of eval() or other dynamic code execution features such as Spring Expression Language (SpEL). Where there is no al… | 1 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.3 Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which a… | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.4 Verify that user-supplied Scalable Vector Graphics (SVG) scriptable content is validated or sanitized to contain only tags and attributes (such as draw graph… | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.5 Verify that the application sanitizes or disables user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets,… | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.6 Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, doma… | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.7 Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alt… | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.8 Verify that the application appropriately sanitizes untrusted input before use in Java Naming and Directory Interface (JNDI) queries and that JNDI is configu… | 2 | Not applicable | — | Not Java (JNDI). |
| V1.3.9 Verify that the application sanitizes content before it is sent to memcache to prevent injection attacks. | 2 | Not applicable | — | No memcache. |
| V1.3.10 Verify that format strings which might resolve in an unexpected or malicious way when used are sanitized before being processed. | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.3.11 Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | 2 | Met | src/openclear/web/templates.py, src/openclear/auth/outbound_http.py |
|
| V1.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. | 2 | Not applicable | — | |
| V1.4.2 Verify that sign, range, and input validation techniques are used to prevent integer overflows. | 2 | Not applicable | — | |
| V1.4.3 Verify that dynamically allocated memory and resources are released, and that references or pointers to freed memory are removed or set to null to prevent da… | 2 | Not applicable | — | |
| V1.5.1 Verify that the application configures XML parsers to use a restrictive configuration and that unsafe features such as resolving external entities are disabl… | 1 | Met | src/openclear/ml/registry.py, src/openclear/auth/saml_service.py |
|
| V1.5.2 Verify that deserialization of untrusted data enforces safe input handling, such as using an allowlist of object types or restricting client-defined object t… | 2 | Met | src/openclear/ml/registry.py, src/openclear/auth/saml_service.py |
V2 Validation and Business Logic
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V2.1.1 Verify that the application's documentation defines input validation rules for how to check the validity of data items against an expected structure. This co… | 1 | Met | docs/security/data-and-limits.md |
|
| V2.1.2 Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that subu… | 2 | Met | docs/security/data-and-limits.md |
|
| V2.1.3 Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application. | 2 | Met | docs/security/data-and-limits.md |
|
| V2.2.1 Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow lis… | 1 | Met | src/openclear/schemas/, src/openclear/bulk_import/ |
|
| V2.2.2 Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability and should be… | 1 | Met | src/openclear/schemas/, src/openclear/bulk_import/ |
|
| V2.2.3 Verify that the application ensures that combinations of related data items are reasonable according to the pre-defined rules. | 2 | Met | src/openclear/schemas/, src/openclear/bulk_import/ |
|
| V2.3.1 Verify that the application will only process business logic flows for the same user in the expected sequential step order and without skipping steps. | 1 | Met | src/openclear/services/change_request_service.py, OC-AC-05, OC-AC-06 |
|
| V2.3.2 Verify that business logic limits are implemented per the application's documentation to avoid business logic flaws being exploited. | 2 | Met | src/openclear/services/change_request_service.py, OC-AC-05, OC-AC-06 |
|
| V2.3.3 Verify that transactions are being used at the business logic level such that either a business logic operation succeeds in its entirety or it is rolled back… | 2 | Met | src/openclear/services/change_request_service.py, OC-AC-05, OC-AC-06 |
|
| V2.3.4 Verify that business logic level locking mechanisms are used to ensure that limited quantity resources (such as theater seats or delivery slots) cannot be do… | 2 | Partly | src/openclear/services/ |
Locking when two people decide the same item at once is to be verified. |
| V2.4.1 Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-d… | 2 | Met | src/openclear/web/rate_limit.py |
V3 Web Frontend Security
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V3.2.1 Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when… | 1 | Met | src/openclear/web/security_headers.py |
|
| V3.2.2 Verify that content intended to be displayed as text, rather than rendered as HTML, is handled using safe rendering functions (such as createTextNode or text… | 1 | Met | src/openclear/web/security_headers.py |
|
| V3.3.1 Verify that cookies have the 'Secure' attribute set, and if the '__Host-' prefix is not used for the cookie name, the '__Secure-' prefix must be used for th… | 1 | Met | src/openclear/web/security.py |
|
| V3.3.2 Verify that each cookie's 'SameSite' attribute value is set according to the purpose of the cookie, to limit exposure to user interface redress attacks and b… | 2 | Met | src/openclear/web/security.py |
|
| V3.3.3 Verify that cookies have the '__Host-' prefix for the cookie name unless they are explicitly designed to be shared with other hosts. | 2 | Met | src/openclear/web/security.py, test_cookie_names_carry_browser_enforced_prefixes_over_https |
|
| V3.3.4 Verify that if the value of a cookie is not meant to be accessible to client-side scripts (such as a session token), the cookie must have the 'HttpOnly' attr… | 2 | Met | src/openclear/web/security.py |
|
| V3.4.1 Verify that a Strict-Transport-Security header field is included on all responses to enforce an HTTP Strict Transport Security (HSTS) policy. A maximum age o… | 1 | Met | src/openclear/web/security_headers.py |
|
| V3.4.2 Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP requ… | 1 | Met | src/openclear/web/security_headers.py |
|
| V3.4.3 Verify that HTTP responses include a Content-Security-Policy response header field which defines directives to ensure the browser only loads and executes tru… | 2 | Met | src/openclear/web/security_headers.py |
|
| V3.4.4 Verify that all HTTP responses contain an 'X-Content-Type-Options: nosniff' header field. This instructs browsers not to use content sniffing and MIME type g… | 2 | Met | src/openclear/web/security_headers.py |
|
| V3.4.5 Verify that the application sets a referrer policy to prevent leakage of technically sensitive data to third-party services via the 'Referer' HTTP request he… | 2 | Met | src/openclear/web/security_headers.py |
|
| V3.4.6 Verify that the web application uses the frame-ancestors directive of the Content-Security-Policy header field for every HTTP response to ensure that it cann… | 2 | Met | src/openclear/web/security_headers.py |
|
| V3.5.1 Verify that, if the application does not rely on the CORS preflight mechanism to prevent disallowed cross-origin requests to use sensitive functionality, the… | 1 | Met | src/openclear/web/security.py |
|
| V3.5.2 Verify that, if the application relies on the CORS preflight mechanism to prevent disallowed cross-origin use of sensitive functionality, it is not possible… | 1 | Met | src/openclear/web/security.py |
|
| V3.5.3 Verify that HTTP requests to sensitive functionality use appropriate HTTP methods such as POST, PUT, PATCH, or DELETE, and not methods defined by the HTTP sp… | 1 | Met | src/openclear/web/security.py |
|
| V3.5.4 Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or s… | 2 | Service provider's (CUEC) | docs/guides/edge.md |
One hostname per installation. |
| V3.5.5 Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is inva… | 2 | Met | src/openclear/web/security.py |
|
| V3.7.1 Verify that the application only uses client-side technologies which are still supported and considered secure. Examples of technologies which do not meet th… | 2 | Met | src/openclear/web/security.py |
|
| V3.7.2 Verify that the application will only automatically redirect the user to a different hostname or domain (which is not controlled by the application) where th… | 2 | Met | src/openclear/web/redirects.py, src/openclear/web/security.py |
Every redirect goes through one helper that takes only a local path; the only ones off the site go to the bank's identity provider. |
V4 API and Web Service
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V4.1.1 Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the chars… | 1 | Met | src/openclear/web/client_ip.py |
|
| V4.1.2 Verify that only user-facing endpoints (intended for manual web-browser access) automatically redirect from HTTP to HTTPS, while other services or endpoints… | 2 | Service provider's (CUEC) | docs/guides/edge.md |
HTTPS redirects at the edge. |
| V4.1.3 Verify that any HTTP header field used by the application and set by an intermediary layer, such as a load balancer, a web proxy, or a backend-for-frontend s… | 2 | Met | src/openclear/web/client_ip.py |
|
| V4.2.1 Verify that all application components (including load balancers, firewalls, and application servers) determine boundaries of incoming HTTP messages using th… | 2 | Service provider's (CUEC) | docs/guides/edge.md |
|
| V4.3.1 Verify that a query allowlist, depth limiting, amount limiting, or query cost analysis is used to prevent GraphQL or data layer expression Denial of Service… | 2 | Not applicable | — | |
| V4.3.2 Verify that GraphQL introspection queries are disabled in the production environment unless the GraphQL API is meant to be used by other parties. | 2 | Not applicable | — | |
| V4.4.1 Verify that WebSocket over TLS (WSS) is used for all WebSocket connections. | 1 | Not applicable | — | |
| V4.4.2 Verify that, during the initial HTTP WebSocket handshake, the Origin header field is checked against a list of origins allowed for the application. | 2 | Not applicable | — | |
| V4.4.3 Verify that, if the application's standard session management cannot be used, dedicated tokens are being used for this, which comply with the relevant Sessio… | 2 | Not applicable | — | |
| V4.4.4 Verify that dedicated WebSocket session management tokens are initially obtained or validated through the previously authenticated HTTPS session when transit… | 2 | Not applicable | — |
V5 File Handling
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V5.1.1 Verify that the documentation defines the permitted file types, expected file extensions, and maximum size (including unpacked size) for each upload feature.… | 2 | Met | docs/security/data-and-limits.md |
|
| V5.2.1 Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack. | 1 | Met | src/openclear/bulk_import/zip_import.py, src/openclear/bulk_import/images.py |
|
| V5.2.2 Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expect… | 1 | Met | src/openclear/bulk_import/zip_import.py, src/openclear/bulk_import/images.py |
|
| V5.2.3 Verify that the application checks compressed files (e.g., zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files… | 2 | Met | src/openclear/bulk_import/zip_import.py, src/openclear/bulk_import/images.py |
|
| V5.3.1 Verify that files uploaded or generated by untrusted input and stored in a public folder, are not executed as server-side program code when accessed directly… | 1 | Met | src/openclear/bulk_import/file_storage.py |
|
| V5.3.2 Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, o… | 1 | Met | src/openclear/storage.py, src/openclear/bulk_import/file_storage.py, test_a_customers_user_cant_write_outside_the_folder, test_through_the_api_too |
Storage refuses any key that isn't a plain relative path inside its area; uploaded names keep only their last part (fixed in 1.25.1). |
| V5.4.1 Verify that the application validates or ignores user-submitted filenames, including in a JSON, JSONP, or URL parameter and specifies a filename in the Conte… | 2 | Met | src/openclear/web/routers/bulk_uploads.py |
|
| V5.4.2 Verify that file names served (e.g., in HTTP response header fields or email attachments) are encoded or sanitized (e.g., following RFC 6266) to preserve doc… | 2 | Met | src/openclear/web/routers/bulk_uploads.py |
|
| V5.4.3 Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent serving of known malicious content. | 2 | Service provider's (CUEC) | src/openclear/services/malware_service.py, docs/security/data-and-limits.md, test_clamav_refuses_malware_and_tells_the_admins |
Every upload checked by ClamAV and VirusTotal hash lookups when the service provider turns them on (OW-D34); the bank's own malware detection either way (B-SI-3-01). |
V6 Authentication
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V6.1.1 Verify that application documentation defines how controls such as rate limiting, anti-automation, and adaptive response, are used to defend against attacks… | 1 | Met | docs/security/authentication.md |
|
| V6.1.2 Verify that a list of context-specific words is documented in order to prevent their use in passwords. The list could include permutations of organization na… | 2 | Met | docs/security/authentication.md |
|
| V6.1.3 Verify that, if the application includes multiple authentication pathways, these are all documented together with the security controls and authentication st… | 2 | Met | docs/security/authentication.md |
|
| V6.2.1 Verify that user set passwords are at least 8 characters in length although a minimum of 15 characters is strongly recommended. | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py, test_new_banks_require_15_characters |
|
| V6.2.2 Verify that users can change their password. | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py |
|
| V6.2.3 Verify that password change functionality requires the user's current and new password. | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py |
|
| V6.2.4 Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords whic… | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py, test_the_bundled_list_knows_common_passwords |
|
| V6.2.5 Verify that passwords of any composition can be used, without rules limiting the type of characters permitted. There must be no requirement for a minimum num… | 1 | Met | src/openclear/auth/password_policy.py |
No composition rules by default; a bank that turns them on doesn't meet this. |
| V6.2.6 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… | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py |
|
| V6.2.7 Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py |
|
| V6.2.8 Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation. | 1 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py, test_every_character_of_a_long_password_counts |
|
| V6.2.9 Verify that passwords of at least 64 characters are permitted. | 2 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py |
|
| V6.2.10 Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credenti… | 2 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py |
|
| V6.2.11 Verify that the documented list of context specific words is used to prevent easy to guess passwords being created. | 2 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py, test_context_words_refuse_names_and_email |
|
| V6.2.12 Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | 2 | Met | src/openclear/auth/password_policy.py, src/openclear/auth/breached_passwords.py, src/openclear/auth/security.py, test_hibp_range_api_sends_only_a_prefix, test_signing_in_with_a_breached_password_forces_a_change |
|
| V6.3.1 Verify that controls to prevent attacks such as credential stuffing and password brute force are implemented according to the application's security document… | 1 | Met | src/openclear/auth/login_service.py, src/openclear/auth/lockout.py, test_the_password_form_follows_the_banks_until_unlocked_policy, test_after_a_lock_runs_out_the_next_wrong_password_locks_again, test_sign_in_attempts_are_limited_per_address, test_parallel_guesses_all_count_and_lock_once |
|
| V6.3.2 Verify that default user accounts (e.g., "root", "admin", or "sa") are not present in the application or are disabled. | 1 | Met | src/openclear/auth/login_service.py |
|
| V6.3.3 Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the a… | 2 | Met | src/openclear/auth/security_key_policy.py, test_after_the_grace_period_a_password_sign_in_needs_a_key, test_platform_sign_in_always_needs_a_security_key |
A bank or customer requires a security key; SSO and embedded sign-ins rely on CUECs B-IA-2(2)-02 and -03. |
| V6.3.4 Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication s… | 2 | Met | src/openclear/auth/login_service.py |
|
| V6.3.5 Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). This may include authentication attempts from an unusual l… | 3 | Met | src/openclear/services/device_service.py, test_a_new_browser_emails_the_person_and_a_known_one_doesnt |
Lockouts and sign-ins from a new browser are emailed (OW-D30). |
| V6.3.6 Verify that email is not used as either a single-factor or multi-factor authentication mechanism. | 3 | Met | src/openclear/auth/login_service.py |
|
| V6.3.7 Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address. | 3 | Met | src/openclear/auth/login_service.py, test_a_recent_session_removes_a_key_and_it_is_recorded_and_emailed, test_a_person_changes_their_own_email_by_a_link_to_the_new_one |
|
| V6.3.8 Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different respo… | 3 | Met | src/openclear/auth/login_service.py, src/openclear/services/sign_in_links.py, test_unknown_and_locked_accounts_spend_a_password_check, test_the_api_answers_a_locked_account_like_a_wrong_password, test_the_page_answers_the_same_for_any_address |
|
| V6.4.1 Verify that system generated initial passwords or activation codes are securely randomly generated, follow the existing password policy, and expire after a s… | 1 | Met | src/openclear/services/password_reset_service.py, src/openclear/services/user_service.py, test_a_reset_link_expires_and_a_newer_one_replaces_it |
|
| V6.4.2 Verify that password hints or knowledge-based authentication (so-called "secret questions") are not present. | 1 | Met | src/openclear/services/password_reset_service.py, src/openclear/services/user_service.py |
|
| V6.4.3 Verify that a secure process for resetting a forgotten password is implemented, that does not bypass any enabled multi-factor authentication mechanisms. | 2 | Met | src/openclear/services/password_reset_service.py, src/openclear/services/user_service.py |
|
| V6.4.4 Verify that if a multi-factor authentication factor is lost, evidence of identity proofing is performed at the same level as during enrollment. | 2 | Met | src/openclear/services/password_reset_service.py, src/openclear/services/user_service.py, test_an_admin_resets_keys_after_saying_how_they_confirmed_it, test_platform_staff_reset_only_a_bank_s_sole_administrator_with_a_second_operator |
|
| V6.4.5 Verify that renewal instructions for authentication mechanisms which expire are sent with enough time to be carried out before the old authentication mechani… | 3 | Not applicable | — | No authenticator expires. |
| V6.4.6 Verify that administrative users can initiate the password reset process for the user, but that this does not allow them to change or choose the user's passw… | 3 | Met | src/openclear/services/password_reset_service.py, src/openclear/services/user_service.py, test_admin_reset_emails_a_one_time_link_the_admin_never_sees |
|
| V6.5.1 Verify that lookup secrets, out-of-band authentication requests or codes, and time-based one-time passwords (TOTPs) are only successfully usable once. | 2 | Not applicable | — | |
| V6.5.2 Verify that, when being stored in the application's backend, lookup secrets with less than 112 bits of entropy (19 random alphanumeric characters or 34 rando… | 2 | Not applicable | — | |
| V6.5.3 Verify that lookup secrets, out-of-band authentication code, and time-based one-time password seeds, are generated using a Cryptographically Secure Pseudoran… | 2 | Not applicable | — | |
| V6.5.4 Verify that lookup secrets and out-of-band authentication codes have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random… | 2 | Not applicable | — | |
| V6.5.5 Verify that out-of-band authentication requests, codes, or tokens, as well as time-based one-time passwords (TOTPs) have a defined lifetime. Out of band requ… | 2 | Not applicable | — | |
| V6.5.6 Verify that any authentication factor (including physical devices) can be revoked in case of theft or other loss. | 3 | Met | src/openclear/services/user_service.py, src/openclear/auth/webauthn_service.py |
The person removes a key; an administrator resets all of them. |
| V6.5.7 Verify that biometric authentication mechanisms are only used as secondary factors together with either something you have or something you know. | 3 | Met | src/openclear/auth/webauthn_service.py |
Biometrics only unlock a WebAuthn authenticator. |
| V6.5.8 Verify that time-based one-time passwords (TOTPs) are checked based on a time source from a trusted service and not from an untrusted or client provided time. | 3 | Not applicable | — | |
| V6.6.1 Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered on… | 2 | Not applicable | — | |
| V6.6.2 Verify that out-of-band authentication requests, codes, or tokens are bound to the original authentication request for which they were generated and are not… | 2 | Not applicable | — | |
| V6.6.3 Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code wit… | 2 | Not applicable | — | |
| V6.6.4 Verify that, where push notifications are used for multi-factor authentication, rate limiting is used to prevent push bombing attacks. Number matching may al… | 3 | Not applicable | — | |
| V6.7.1 Verify that the certificates used to verify cryptographic authentication assertions are stored in a way protects them from modification. | 3 | Met | src/openclear/auth/webauthn_service.py |
|
| V6.7.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. | 3 | Met | src/openclear/auth/webauthn_service.py |
|
| V6.8.1 Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (e… | 2 | Met | src/openclear/services/sso_service.py, src/openclear/auth/oidc_service.py, src/openclear/auth/saml_service.py |
|
| V6.8.2 Verify that the presence and integrity of digital signatures on authentication assertions (for example on JWTs or SAML assertions) are always validated, reje… | 2 | Met | src/openclear/services/sso_service.py, src/openclear/auth/oidc_service.py, src/openclear/auth/saml_service.py |
|
| V6.8.3 Verify that SAML assertions are uniquely processed and used only once within the validity period to prevent replay attacks. | 2 | Met | src/openclear/services/sso_service.py, src/openclear/auth/oidc_service.py, src/openclear/auth/saml_service.py |
|
| V6.8.4 Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific func… | 2 | Met | src/openclear/services/sso_service.py, src/openclear/auth/oidc_service.py, src/openclear/auth/saml_service.py, test_a_connection_can_require_the_provider_to_report_mfa |
V7 Session Management
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V7.1.1 Verify that the user's session inactivity timeout and absolute maximum session lifetime are documented, are appropriate in combination with other controls, a… | 2 | Met | docs/security/authentication.md |
|
| V7.1.2 Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviors and actions to be… | 2 | Met | docs/security/authentication.md |
|
| V7.1.3 Verify that all systems that create and manage user sessions as part of a federated identity management ecosystem (such as SSO systems) are documented along… | 2 | Met | docs/security/authentication.md |
|
| V7.2.1 Verify that the application performs all session token verification using a trusted, backend service. | 1 | Met | src/openclear/auth/security.py, src/openclear/services/session_service.py |
|
| V7.2.2 Verify that the application uses either self-contained or reference tokens that are dynamically generated for session management, i.e. not using static API s… | 1 | Met | src/openclear/auth/security.py, src/openclear/services/session_service.py |
|
| V7.2.3 Verify that if reference tokens are used to represent user sessions, they are unique and generated using a cryptographically secure pseudo-random number gene… | 1 | Met | src/openclear/auth/security.py, src/openclear/services/session_service.py |
|
| V7.2.4 Verify that the application generates a new session token on user authentication, including re-authentication, and terminates the current session token. | 1 | Met | src/openclear/auth/security.py, src/openclear/services/session_service.py |
|
| V7.3.1 Verify that there is an inactivity timeout such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | Met | src/openclear/auth/security.py |
|
| V7.3.2 Verify that there is an absolute maximum session lifetime such that re-authentication is enforced according to risk analysis and documented security decisions. | 2 | Met | src/openclear/auth/security.py |
|
| V7.4.1 Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session. For reference tok… | 1 | Met | src/openclear/services/session_service.py, src/openclear/web/security.py |
|
| V7.4.2 Verify that the application terminates all active sessions when a user account is disabled or deleted (such as an employee leaving the company). | 1 | Met | src/openclear/services/session_service.py, src/openclear/web/security.py |
|
| V7.4.3 Verify that the application gives the option to terminate all other active sessions after a successful change or removal of any authentication factor (includ… | 2 | Met | src/openclear/services/session_service.py, src/openclear/web/security.py |
|
| V7.4.4 Verify that all pages that require authentication have easy and visible access to logout functionality. | 2 | Met | src/openclear/services/session_service.py, src/openclear/web/security.py |
|
| V7.4.5 Verify that application administrators are able to terminate active sessions for an individual user or for all users. | 2 | Met | src/openclear/services/session_service.py, test_an_admin_signs_everyone_out_but_themselves |
One person, or everyone at the bank or customer at once (OW-D29). |
| V7.5.1 Verify that the application requires full re-authentication before allowing modifications to sensitive account attributes which may affect authentication suc… | 2 | Met | src/openclear/auth/deps.py, test_a_stale_session_cant_change_keys_on_the_web |
|
| V7.5.2 Verify that users are able to view and (having authenticated again with at least one factor) terminate any or all currently active sessions. | 2 | Met | src/openclear/web/routers/security_settings.py, test_a_person_sees_their_sessions_and_ends_another |
A list of sessions, each signed out on its own, after a recent sign-in (OW-D29). |
| V7.5.3 Verify that the application requires further authentication with at least one factor or secondary verification before performing highly sensitive transaction… | 3 | Met | src/openclear/services/change_request_service.py |
Sensitive changes and decisions take a second person (dual control). |
| V7.6.1 Verify that session lifetime and termination between Relying Parties (RPs) and Identity Providers (IdPs) behave as documented, requiring re-authentication as… | 2 | Met | docs/security/authentication.md |
|
| V7.6.2 Verify that creation of a session requires either the user's consent or an explicit action, preventing the creation of new application sessions without user… | 2 | Met | docs/security/authentication.md |
V8 Authorization
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V8.1.1 Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attr… | 1 | Met | docs/security/authorization.md |
|
| V8.1.2 Verify that authorization documentation defines rules for field-level access restrictions (both read and write) based on consumer permissions and resource at… | 2 | Met | docs/security/authorization.md |
|
| V8.1.3 Verify that the application's documentation defines the environmental and contextual attributes (including but not limited to, time of day, user location, IP… | 3 | Not met | — | Level 3: no adaptive controls; OpenClear sits behind the bank's edge and identity provider (OW-D27). |
| V8.1.4 Verify that authentication and authorization documentation defines how environmental and contextual factors are used in decision-making, in addition to funct… | 3 | Not met | — | Level 3: as 8.1.3 (OW-D27). |
| V8.2.1 Verify that the application ensures that function-level access is restricted to consumers with explicit permissions. | 1 | Met | src/openclear/auth/permissions.py, src/openclear/db/tenancy.py, src/openclear/db/account_scope.py |
|
| V8.2.2 Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecur… | 1 | Met | src/openclear/auth/permissions.py, src/openclear/db/tenancy.py, src/openclear/db/account_scope.py |
|
| V8.2.3 Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object… | 2 | Met | src/openclear/auth/permissions.py, src/openclear/db/tenancy.py, src/openclear/db/account_scope.py |
|
| V8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) a… | 3 | Not met | — | Level 3: as 8.1.3 (OW-D27). |
| V8.3.1 Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate,… | 1 | Met | src/openclear/auth/deps.py |
|
| V8.3.2 Verify that changes to values on which authorization decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when r… | 3 | Met | src/openclear/auth/deps.py |
|
| V8.3.3 Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service ac… | 3 | Met | src/openclear/auth/deps.py |
|
| V8.4.1 Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissio… | 2 | Met | src/openclear/db/tenancy.py |
|
| V8.4.2 Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device securit… | 3 | Partly | src/openclear/web/routers/platform.py |
Level 3: platform staff need a key and a bank's grant; no device posture checks (OW-D27). |
V9 Self-contained Tokens
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V9.1.1 Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | 1 | Met | src/openclear/auth/security.py, src/openclear/auth/client_assertion.py |
|
| V9.1.2 Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permi… | 1 | Met | src/openclear/auth/security.py, src/openclear/auth/client_assertion.py |
|
| V9.1.3 Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers fro… | 1 | Met | src/openclear/auth/security.py, src/openclear/auth/client_assertion.py |
|
| V9.2.1 Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validi… | 1 | Met | src/openclear/auth/security.py |
|
| V9.2.2 Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's conte… | 2 | Met | src/openclear/auth/security.py |
|
| V9.2.3 Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' c… | 2 | Met | src/openclear/auth/security.py, test_tokens_name_this_installation_and_their_purpose |
|
| V9.2.4 Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that un… | 2 | Met | src/openclear/auth/security.py, test_a_token_without_an_issuer_and_audience_is_refused |
V10 OAuth and OIDC
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V10.1.1 Verify that tokens are only sent to components that strictly need them. For example, when using a backend-for-frontend pattern for browser-based JavaScript a… | 2 | Met | src/openclear/auth/oidc_service.py |
|
| V10.1.2 Verify that the client only accepts values from the authorization server (such as the authorization code or ID Token) if these values result from an authoriz… | 2 | Met | src/openclear/auth/oidc_service.py |
|
| V10.2.1 Verify that, if the code flow is used, the OAuth client has protection against browser-based request forgery attacks, commonly known as cross-site request fo… | 2 | Met | src/openclear/auth/oidc_service.py |
|
| V10.2.2 Verify that, if the OAuth client can interact with more than one authorization server, it has a defense against mix-up attacks. For example, it could require… | 2 | Met | src/openclear/auth/oidc_service.py |
|
| V10.2.3 Verify that the OAuth client only requests the required scopes (or other authorization parameters) in requests to the authorization server. | 3 | Met | src/openclear/auth/oidc_service.py |
|
| V10.3.1 Verify that the resource server only accepts access tokens that are intended for use with that service (audience). The audience may be included in a structur… | 2 | Met | src/openclear/auth/deps.py |
|
| V10.3.2 Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If claims such as… | 2 | Met | src/openclear/auth/deps.py |
|
| V10.3.3 Verify that if an access control decision requires identifying a unique user from an access token (JWT or related token introspection response), the resource… | 2 | Met | src/openclear/auth/deps.py |
|
| V10.3.4 Verify that, if the resource server requires specific authentication strength, methods, or recentness, it verifies that the presented access token satisfies… | 2 | Not applicable | — | No per-function authentication strength from access tokens. |
| V10.3.5 Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrain… | 3 | Not met | — | Level 3: no sender-constrained tokens (DPoP, mTLS); no bank's core can send them (OW-D26). |
| V10.4.1 Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison. | 1 | Not applicable | — | No authorization-code grant. |
| V10.4.2 Verify that, if the authorization server returns the authorization code in the authorization response, it can be used only once for a token request. For the… | 1 | Not applicable | — | No authorization-code grant. |
| V10.4.3 Verify that the authorization code is short-lived. The maximum lifetime can be up to 10 minutes for L1 and L2 applications and up to 1 minute for L3 applicat… | 1 | Not applicable | — | No authorization-code grant. |
| V10.4.4 Verify that for a given client, the authorization server only allows the usage of grants that this client needs to use. Note that the grants 'token' (Implici… | 1 | Met | src/openclear/api/v1/oauth.py |
Only client credentials and token exchange. |
| V10.4.5 Verify that the authorization server mitigates refresh token replay attacks for public clients, preferably using sender-constrained refresh tokens, i.e., Dem… | 1 | Not applicable | — | No public clients. |
| V10.4.6 Verify that, if the code grant is used, the authorization server mitigates authorization code interception attacks by requiring proof key for code exchange (… | 2 | Not applicable | — | No authorization-code grant. |
| V10.4.7 Verify that if the authorization server supports unauthenticated dynamic client registration, it mitigates the risk of malicious client applications. It must… | 2 | Not applicable | — | No dynamic client registration. |
| V10.4.8 Verify that refresh tokens have an absolute expiration, including if sliding refresh token expiration is applied. | 2 | Met | src/openclear/api/v1/oauth.py |
|
| V10.4.9 Verify that refresh tokens and reference access tokens can be revoked by an authorized user using the authorization server user interface, to mitigate the ri… | 2 | Met | src/openclear/api/v1/oauth.py |
|
| V10.4.10 Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, pushed authorization requests (… | 2 | Met | src/openclear/api/v1/oauth.py |
|
| V10.4.11 Verify that the authorization server configuration only assigns the required scopes to the OAuth client. | 2 | Met | src/openclear/api/v1/oauth.py |
|
| V10.4.12 Verify that for a given client, the authorization server only allows the 'response_mode' value that this client needs to use. For example, by having the auth… | 3 | Not applicable | — | No response_mode. |
| V10.4.13 Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | 3 | Not applicable | — | No authorization-code grant. |
| V10.4.14 Verify that the authorization server issues only sender-constrained (Proof-of-Possession) access tokens, either with certificate-bound access tokens using mu… | 3 | Not met | — | Level 3: as 10.3.5 (OW-D26). |
| V10.4.15 Verify that, for a server-side client (which is not executed on the end-user device), the authorization server ensures that the 'authorization_details' param… | 3 | Not applicable | — | No authorization_details. |
| V10.4.16 Verify that the client is confidential and the authorization server requires the use of strong client authentication methods (based on public-key cryptograph… | 3 | Met | src/openclear/api/v1/oauth.py, test_a_bank_can_require_key_pairs |
Key pairs can be required per bank (OW-D26). |
| V10.5.1 Verify that the client (as the relying party) mitigates ID Token replay attacks. For example, by ensuring that the 'nonce' claim in the ID Token matches the… | 2 | Met | src/openclear/auth/oidc_service.py, src/openclear/services/sso_service.py |
|
| V10.5.2 Verify that the client uniquely identifies the user from ID Token claims, usually the 'sub' claim, which cannot be reassigned to other users (for the scope o… | 2 | Met | src/openclear/auth/oidc_service.py, src/openclear/services/sso_service.py, test_a_reassigned_email_is_refused |
|
| V10.5.3 Verify that the client rejects attempts by a malicious authorization server to impersonate another authorization server through authorization server metadata… | 2 | Met | src/openclear/auth/oidc_service.py, src/openclear/services/sso_service.py |
|
| V10.5.4 Verify that the client validates that the ID Token is intended to be used for that client (audience) by checking that the 'aud' claim from the token is equal… | 2 | Met | src/openclear/auth/oidc_service.py, src/openclear/services/sso_service.py |
|
| V10.5.5 Verify that, when using OIDC back-channel logout, the relying party mitigates denial of service through forced logout and cross-JWT confusion in the logout f… | 2 | Met | src/openclear/auth/oidc_service.py, src/openclear/services/sso_service.py |
|
| V10.6.1 Verify that the OpenID Provider only allows values 'code', 'ciba', 'id_token', or 'id_token code' for response mode. Note that 'code' is preferred over 'id_t… | 2 | Not applicable | — | |
| V10.6.2 Verify that the OpenID Provider mitigates denial of service through forced logout. By obtaining explicit confirmation from the end-user or, if present, valid… | 2 | Not applicable | — | |
| V10.7.1 Verify that the authorization server ensures that the user consents to each authorization request. If the identity of the client cannot be assured, the autho… | 2 | Not applicable | — | |
| V10.7.2 Verify that when the authorization server prompts for user consent, it presents sufficient and clear information about what is being consented to. When appli… | 2 | Not applicable | — | |
| V10.7.3 Verify that the user can review, modify, and revoke consents which the user has granted through the authorization server. | 2 | Not applicable | — |
V11 Cryptography
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V11.1.1 Verify that there is a documented policy for management of cryptographic keys and a cryptographic key lifecycle that follows a key management standard such a… | 2 | Met | docs/security/cryptography.md |
|
| V11.1.2 Verify that a cryptographic inventory is performed, maintained, regularly updated, and includes all cryptographic keys, algorithms, and certificates used by… | 2 | Met | docs/security/cryptography.md |
|
| V11.1.3 Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signi… | 3 | Met | docs/security/cryptography.md |
|
| V11.1.4 Verify that a cryptographic inventory is maintained. This must include a documented plan that outlines the migration path to new cryptographic standards, suc… | 3 | Met | docs/security/cryptography.md |
|
| V11.2.1 Verify that industry-validated implementations (including libraries and hardware-accelerated implementations) are used for cryptographic operations. | 2 | Met | src/openclear/auth/crypto.py |
|
| V11.2.2 Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC, or hashing algorithms, key lengths, round… | 2 | Met | src/openclear/auth/crypto.py |
|
| V11.2.3 Verify that all cryptographic primitives utilize a minimum of 128-bits of security based on the algorithm, key size, and configuration. For example, a 256-bi… | 2 | Partly | src/openclear/auth/saml_service.py, test_new_saml_connections_get_rsa_3072_keys |
SAML connections made before 1.22.1 keep RSA-2048 keys until replaced (issue #21). |
| V11.2.4 Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking inf… | 3 | Met | src/openclear/auth/crypto.py |
|
| V11.2.5 Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | 3 | Met | src/openclear/auth/crypto.py |
|
| V11.3.1 Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | 1 | Met | src/openclear/auth/crypto.py |
|
| V11.3.2 Verify that only approved ciphers and modes such as AES with GCM are used. | 1 | Met | src/openclear/auth/crypto.py |
|
| V11.3.3 Verify that encrypted data is protected against unauthorized modification preferably by using an approved authenticated encryption method or by combining an… | 2 | Met | src/openclear/auth/crypto.py |
|
| V11.3.4 Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key and data-element pair. The method of g… | 3 | Met | src/openclear/auth/crypto.py |
|
| V11.3.5 Verify that any combination of an encryption algorithm and a MAC algorithm is operating in encrypt-then-MAC mode. | 3 | Met | src/openclear/auth/crypto.py |
|
| V11.4.1 Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Di… | 1 | Met | src/openclear/auth/security.py |
|
| V11.4.2 Verify that passwords are stored using an approved, computationally intensive, key derivation function (also known as a "password hashing function"), with pa… | 2 | Met | src/openclear/auth/security.py |
|
| V11.4.3 Verify that hash functions used in digital signatures, as part of data authentication or data integrity are collision resistant and have appropriate bit-leng… | 2 | Met | src/openclear/auth/security.py |
|
| V11.4.4 Verify that the application uses approved key derivation functions with key stretching parameters when deriving secret keys from passwords. The parameters in… | 2 | Not applicable | — | No keys are derived from passwords. |
| V11.5.1 Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number gen… | 2 | Met | src/openclear/auth/security.py |
|
| V11.5.2 Verify that the random number generation mechanism in use is designed to work securely, even under heavy demand. | 3 | Met | src/openclear/auth/security.py |
|
| V11.6.1 Verify that only approved cryptographic algorithms and modes of operation are used for key generation and seeding, and digital signature generation and verif… | 2 | Met | src/openclear/auth/keys.py |
|
| V11.6.2 Verify that approved cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use se… | 3 | Service provider's (CUEC) | docs/guides/edge.md |
TLS key exchange is at the edge. |
| V11.7.1 Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | 3 | Service provider's (CUEC) | — | |
| V11.7.2 Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as… | 3 | Partly | docs/security/authorization.md |
Access is limited by scope; account numbers aren't masked. |
V12 Secure Communication
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V12.1.1 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 must be… | 1 | Service provider's (CUEC) | docs/guides/edge.md, test_siem_tls_needs_1_2_or_newer |
|
| V12.1.2 Verify that only recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites wh… | 2 | Service provider's (CUEC) | docs/guides/edge.md |
|
| V12.1.3 Verify that the application validates that mTLS client certificates are trusted before using the certificate identity for authentication or authorization. | 2 | Service provider's (CUEC) | docs/guides/edge.md |
|
| V12.2.1 Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted com… | 1 | Service provider's (CUEC) | docs/guides/edge.md |
|
| V12.2.2 Verify that external facing services use publicly trusted TLS certificates. | 1 | Service provider's (CUEC) | docs/guides/edge.md |
|
| V12.3.1 Verify that an encrypted protocol such as TLS is used for all inbound and outbound connections to and from the application, including monitoring systems, man… | 2 | Partly | src/openclear/auth/outbound_http.py |
Outbound calls use TLS; database and Redis TLS are the service provider's. |
| V12.3.2 Verify that TLS clients validate certificates received before communicating with a TLS server. | 2 | Met | src/openclear/auth/outbound_http.py, src/openclear/services/siem/senders.py, test_production_refuses_unverified_siem_tls |
|
| V12.3.3 Verify that TLS or another appropriate transport encryption mechanism used for all connectivity between internal, HTTP-based services within the application,… | 2 | Service provider's (CUEC) | — | TLS between internal services. |
| V12.3.4 Verify that TLS connections between internal services use trusted certificates. Where internally generated or self-signed certificates are used, the consumin… | 2 | Service provider's (CUEC) | — | Certificates between internal services. |
V13 Configuration
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V13.1.1 Verify that all communication needs for the application are documented. This must include external services which the application relies upon and cases where… | 2 | Met | docs/security/data-and-limits.md |
|
| V13.2.1 Verify that communications between backend application components that don't support the application's standard user session mechanism, including APIs, middl… | 2 | Met | src/openclear/auth/outbound_http.py |
|
| V13.2.2 Verify that communications between backend application components, including local or operating system services, APIs, middleware, and data layers, are perfo… | 2 | Met | src/openclear/auth/outbound_http.py |
|
| V13.2.3 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… | 2 | Met | src/openclear/auth/outbound_http.py |
|
| V13.2.4 Verify that an allowlist is used to define the external resources or systems with which the application is permitted to communicate (e.g., for outbound reque… | 2 | Partly | src/openclear/auth/outbound_http.py |
Outbound limited to public addresses and configured destinations, not an allowlist. |
| V13.2.5 Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files… | 2 | Partly | src/openclear/auth/outbound_http.py |
As 13.2.4. |
| V13.3.1 Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets. These coul… | 2 | Service provider's (CUEC) | src/openclear/config.py |
|
| V13.3.2 Verify that access to secret assets adheres to the principle of least privilege. | 2 | Service provider's (CUEC) | src/openclear/config.py |
|
| V13.4.1 Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are in… | 1 | Met | src/openclear/main.py |
|
| V13.4.2 Verify that debug modes are disabled for all components in production environments to prevent exposure of debugging features and information leakage. | 2 | Met | src/openclear/main.py |
|
| V13.4.3 Verify that web servers do not expose directory listings to clients unless explicitly intended. | 2 | Met | src/openclear/main.py |
|
| V13.4.4 Verify that using the HTTP TRACE method is not supported in production environments, to avoid potential information leakage. | 2 | Met | src/openclear/main.py |
|
| V13.4.5 Verify that documentation (such as for internal APIs) and monitoring endpoints are not exposed unless explicitly intended. | 2 | Met | src/openclear/main.py, test_api_docs_pages_can_be_turned_off |
V14 Data Protection
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V14.1.1 Verify that all sensitive data created and processed by the application has been identified and classified into protection levels. This includes data that is… | 2 | Met | docs/security/risk-profile.md |
|
| V14.1.2 Verify that all sensitive data protection levels have a documented set of protection requirements. This must include (but not be limited to) requirements rel… | 2 | Met | docs/security/risk-profile.md |
|
| V14.2.1 Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive i… | 1 | Met | src/openclear/web/list_search.py, docs/guides/edge.md, test_search_finds_items_on_any_page |
Searches are posted; list filters carry account ids, not numbers; the access log records paths only, and the edge guide says to drop query strings (OW-D35). |
| V14.2.2 Verify that the application prevents sensitive data from being cached in server components, such as load balancers and application caches, or ensures that th… | 2 | Met | src/openclear/web/security_headers.py |
|
| V14.2.3 Verify that defined sensitive data is not sent to untrusted parties (e.g., user trackers) to prevent unwanted collection of data outside of the application's… | 2 | Met | src/openclear/web/security_headers.py |
|
| V14.2.4 Verify that controls around sensitive data related to encryption, integrity verification, retention, how the data is to be logged, access controls around sen… | 2 | Met | src/openclear/web/security_headers.py |
|
| V14.3.1 Verify that authenticated data is cleared from client storage, such as the browser DOM, after the client or session is terminated. The 'Clear-Site-Data' HTTP… | 1 | Met | src/openclear/web/security.py, test_ending_a_session_clears_the_browser_s_cache_and_storage |
|
| V14.3.2 Verify that the application sets sufficient anti-caching HTTP response header fields (i.e., Cache-Control: no-store) so that sensitive data is not cached in… | 2 | Met | src/openclear/web/security.py |
|
| V14.3.3 Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data, with the exception… | 2 | Met | src/openclear/web/security.py |
V15 Secure Coding and Architecture
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V15.1.1 Verify that application documentation defines risk based remediation time frames for 3rd party component versions with vulnerabilities and for updating libra… | 1 | Met | SECURITY.md, docs/security/data-and-limits.md |
|
| V15.1.2 Verify that an inventory catalog, such as software bill of materials (SBOM), is maintained of all third-party libraries in use, including verifying that comp… | 2 | Met | SECURITY.md, docs/security/data-and-limits.md |
|
| V15.1.3 Verify that the application documentation identifies functionality which is time-consuming or resource-demanding. This must include how to prevent a loss of… | 2 | Met | SECURITY.md, docs/security/data-and-limits.md |
|
| V15.2.1 Verify that the application only contains components which have not breached the documented update and remediation time frames. | 1 | Met | requirements/runtime.txt, scripts/sbom.py |
|
| V15.2.2 Verify that the application has implemented defenses against loss of availability due to functionality which is time-consuming or resource-demanding, based o… | 2 | Met | requirements/runtime.txt, scripts/sbom.py |
|
| V15.2.3 Verify that the production environment only includes functionality that is required for the application to function, and does not expose extraneous functiona… | 2 | Met | requirements/runtime.txt, scripts/sbom.py |
|
| V15.3.1 Verify that the application only returns the required subset of fields from a data object. For example, it should not return an entire data object, as some i… | 1 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
|
| V15.3.2 Verify that where the application backend makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality. | 2 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
|
| V15.3.3 Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is… | 2 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
|
| V15.3.4 Verify that all proxying and middleware components transfer the user's original IP address correctly using trusted data fields that cannot be manipulated by… | 2 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
|
| V15.3.5 Verify that the application explicitly ensures that variables are of the correct type and performs strict equality and comparator operations. This is to avoi… | 2 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
|
| V15.3.6 Verify that JavaScript code is written in a way that prevents prototype pollution, for example, by using Set() or Map() instead of object literals. | 2 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
|
| V15.3.7 Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the s… | 2 | Met | src/openclear/schemas/, src/openclear/web/client_ip.py |
V16 Security Logging and Error Handling
| Requirement | Level | Status | Evidence | Note |
|---|---|---|---|---|
| V16.1.1 Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log form… | 2 | Met | docs/guides/siem.md |
|
| V16.2.1 Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an… | 2 | Met | src/openclear/services/security_events.py, src/openclear/logging_config.py |
|
| V16.2.2 Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone… | 2 | Met | src/openclear/services/security_events.py, src/openclear/logging_config.py |
|
| V16.2.3 Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory. | 2 | Met | src/openclear/services/security_events.py, src/openclear/logging_config.py |
|
| V16.2.4 Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format. | 2 | Met | src/openclear/services/security_events.py, src/openclear/logging_config.py |
|
| V16.2.5 Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log cer… | 2 | Met | src/openclear/services/security_events.py, src/openclear/logging_config.py |
|
| V16.3.1 Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication… | 2 | Met | src/openclear/services/security_events.py |
|
| V16.3.2 Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is… | 2 | Partly | src/openclear/services/security_events.py, src/openclear/web/routers/check_images.py |
Denials, exports and check-image views are logged; other pages that show sensitive data aren't, to keep the log useful (OW-D28). |
| V16.3.3 Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as in… | 2 | Met | src/openclear/services/security_events.py |
|
| V16.3.4 Verify that the application logs unexpected errors and security control failures such as backend TLS failures. | 2 | Met | src/openclear/services/security_events.py |
|
| V16.4.1 Verify that all logging components appropriately encode data to prevent log injection. | 2 | Met | src/openclear/services/audit_log_service.py, src/openclear/logging_config.py, test_text_logs_escape_line_breaks_so_input_cant_forge_a_line |
|
| V16.4.2 Verify that logs are protected from unauthorized access and cannot be modified. | 2 | Met | src/openclear/services/audit_log_service.py, src/openclear/logging_config.py |
|
| V16.4.3 Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the… | 2 | Met | src/openclear/services/audit_log_service.py, src/openclear/logging_config.py |
|
| V16.5.1 Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal s… | 2 | Met | src/openclear/main.py |
|
| V16.5.2 Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or gra… | 2 | Met | src/openclear/main.py |
|
| V16.5.3 Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transacti… | 2 | Met | src/openclear/main.py |
|
| V16.5.4 Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to lo… | 3 | Met | src/openclear/main.py |
Built from docs/compliance/asvs.md in the OpenClear repository. Last changed October 22, 2026.