Security
Security according to OWASP ASVS 5.0
We assess Complass against the international standard for secure web applications and disclose where we stand. Only fully implemented requirements are counted.
Status by level
As of 21.10.2026, version 2.05.2 · self-assessment, kept in the control register
- Level 1 · Baseline 98% implemented 61 of 62 implemented
- Level 2 · Standard for business data 93% implemented 188 of 203 applicable requirements implemented, 1 deliberately accepted residual risk (not counted)
- Level 3 · Highly critical applications 85% implemented Voluntary, beyond the standard. Level 3 is meant for systems such as payment processing. As of 21.10.2026
- 203Level 1 and 2 requirements
- 188of them fully implemented
- > 10,000automated tests on every change
- 21.10.2026last assessment
Justified exceptions (not counted as met)
-
Key length of third parties (V11.2.3, Level 2): RSA-2048 from identity providers and passkey devices – permitted under NIST SP 800-131A until the end of 2030.
Why?
Complass itself encrypts throughout with at least 128 bits of security (256-bit keys). Identity providers such as Microsoft or Google and many passkey devices, however, sign with RSA-2048 (112 bits). We accept these keys in line with NIST SP 800-131A until the end of 2030; from 2031 we require at least RSA-3072. If we rejected RSA-2048 today, signing in with SSO and passkeys would no longer be possible.
Areas assessed
All 17 chapters of the standard are assessed.
- Encoding and Sanitization
- Validation and Business Logic
- Web Frontend Security
- API and Web Service
- File Handling
- Authentication
- Session Management
- Authorization
- Self-contained Tokens
- OAuth and OIDC
- Cryptography
- Secure Communication
- Configuration
- Data Protection
- Secure Coding and Architecture
- Security Logging and Error Handling
- WebRTC
Every requirement with status and evidence
For customers, prospects under a non-disclosure agreement and auditors, in the Trust Center.
Request Trust Center accessWhat does “not applicable” mean?
Some requirements concern technology Complass does not use, such as LDAP, LaTeX or WebRTC. They count neither as implemented nor as open.
How are the levels counted?
Level 2 includes all Level 1 requirements. The Level 2 figure therefore counts Level 1 and 2 together.
What this means for you
Ten things behind the numbers. For each you see how many requirements behind it are implemented in the control register.
-
Sign-in like at a bank
Two-factor for everyone, passkeys, protection against guessed and already leaked passwords and a lockout against brute force.
For you this means: A stolen password alone does not open an account.
V6 · 31 of 31 requirements implemented
-
Sessions nobody can take over
Secure cookies, sign-out on all devices and re-confirmation for critical actions.
For you this means: A forgotten browser window does not become a way in.
V7 · 18 of 18 requirements implemented
-
Everyone sees only what they may
Strict separation of companies, rights per person and area, checked on the server.
For you this means: Advisers, suppliers and auditors see only what you release.
V8 · 7 of 7 requirements implemented
-
Your data encrypted, even from us
Own key per customer, insight by us only with your time-limited approval; on deletion the key is destroyed.
For you this means: Even we cannot reach your content without your approval.
V11 · V14 · 19 of 22 requirements implemented
-
Uploads without risk
Files are checked, scanned for malware and stored encrypted outside the publicly reachable directory.
For you this means: A tampered document does not become a danger to your team.
V5 · 8 of 9 requirements implemented
-
Transferred securely
Encrypted connections with HSTS, own server in Germany, outgoing connections only via https to public addresses.
For you this means: Your data stays under control in transit and in operation.
V12 · V13 · 13 of 19 requirements implemented
-
Logged and traceable
A chain that exposes later changes and a log that also covers read access.
For you this means: You see who did what and when, and can show it to an auditor.
V16 · 14 of 16 requirements implemented
-
Protection against typical attacks
Input is validated, output encoded; protection against code injection, forged requests (CSRF) and access to internal targets.
For you this means: The most common attack paths are closed before they can be used.
V1 · V2 · V3 · 47 of 48 requirements implemented
-
Secure interfaces
API access only with a key, every call is logged.
For you this means: Connections to your tools do not open a back door.
V4 · 2 of 4 requirements implemented
-
Built cleanly
Security checks run on every change, and the automated tests block the release if one fails.
For you this means: Security is part of development, not a coat of paint at the end.
V15 · 13 of 13 requirements implemented
Self-assessment with a verifiable control register: auditors, customers and prospects under a non-disclosure agreement see every single requirement with status and evidence in the Trust Center.