🔐 Security FAQ
FluentCase has completed a CASA (Cloud Application Security Assessment) security verification conducted by our security provider. The questions and answers below are derived from that assessment and describe the security controls protecting your data.
For a higher-level overview of our security posture, see our Security & Privacy Overview.
Authentication & Two-Factor Authentication
Is two-factor authentication (2FA) required? Yes. 2FA is enabled by default for all accounts. Our default login mode is passwordless — users authenticate via a secure, short-lived code sent to their email address rather than a static password.
How long are 2FA codes valid? 2FA codes expire within three minutes of being issued — well within the industry-standard 10-minute threshold.
How are 2FA codes generated? Authentication codes consist of 12 alphanumeric characters generated by a cryptographically-secure random number generator, providing well in excess of 20 bits of entropy as required by OWASP ASVS.
Are administrative interfaces protected by MFA? Yes. 2FA is the application default for all users, including administrators.
What happens if I change my password? A password change immediately invalidates all existing active sessions on all devices.
Session & Token Management
How are session tokens managed? The application uses session tokens for all authenticated access. Tokens are invalidated upon logout or expiration and cannot be reused to resume a session — including via browser back-button navigation or other path traversal techniques. Session expiration behavior is verified in our automated test suite on every build.
Are session tokens or API keys exposed in URLs? No. API URLs never contain session tokens, API keys, or any other sensitive information.
What data is stored in the browser? Only a session cookie is stored in the browser, containing the minimal data required to maintain an active session. No case data, credentials, or sensitive information is stored in localStorage, sessionStorage, IndexedDB, or any other browser storage mechanism.
Is sensitive data ever sent in URL query strings? No. Sensitive data is always transmitted in the HTTP message body or headers — never in query string parameters.
Does the application use session tokens or static API secrets? Session tokens are used for all authenticated application access. A small number of static keys exist for explicitly semi-public, non-sensitive features (e.g., sharing calendar availability with external parties).
Access Control & Authorization
How does FluentCase enforce access control? Authorization is enforced at every application layer: at the URI level via controller/router middleware, and at the resource level via model-based permissions. Client-side access controls mirror server-side logic but are treated as informational only — they are never trusted as authoritative.
Does FluentCase follow the principle of least privilege? Yes. Users are explicitly granted access on a per-resource and per-data basis. All other access is denied by default.
Are user roles and permissions protected from tampering? Yes. User roles, policy settings, and access controls can only be modified by specifically authorized administrators. End users cannot manipulate their own permission attributes.
What happens when an access control check fails? Access controls fail securely. The application returns minimal 4xx or 5xx error responses. Stack traces, internal error details, and sensitive data are explicitly suppressed from all error output.
How are IDOR (Insecure Direct Object Reference) attacks handled? Every interaction passes through FluentCase’s authorization and ACL checks. Attempts to access records via direct object reference manipulation return a 404 response — revealing no information about the existence of the resource.
Can the HTTP Origin header bypass authentication? No. The Origin header is ignored entirely by our authentication and authorization systems.
What RESTful HTTP methods are permitted per user role? All endpoints enforce authentication and ACL verification. Users cannot invoke HTTP methods (e.g., DELETE, PUT) on resources for which they lack explicit authorization.
Password Security
How are passwords stored? Passwords are stored using a salted, one-way key derivation function with per-user salt and industry-standard cost parameters, providing strong resistance to offline brute-force and dictionary attacks.
Are default or shared accounts used? No. No default accounts (e.g., “root”, “admin”, “sa”) are present at any layer — application, server, or database.
How are system-generated temporary credentials handled? System-generated credentials use cryptographically secure random generation and are not permitted to become long-term passwords.
Data Protection & Encryption
Is data encrypted at rest? Yes. All data — including regulated personal information and PII subject to GDPR — is encrypted at rest.
Is data encrypted in transit? Yes. All connections use trusted TLS certificates. Local CAs and self-signed certificates are not accepted.
Is certificate revocation checked? Yes. OCSP Stapling is enabled and active on all servers.
Are credentials or payment details ever logged? No. Credentials and payment details are never logged or stored except in irreversible, hashed form.
Is sensitive data protected from server-side caching? Yes. Sensitive data is served with explicit HTTP headers that prevent caching by load balancers and application caches.
How is sensitive data access audited? Access to and changes of sensitive data are logged — recording metadata (type of data, not the values themselves) where required under applicable data protection regulations.
Cryptography
How are GUIDs and unique identifiers generated?
All GUIDs are generated using the UUID v4 algorithm via the ramsey/uuid library, which uses a Cryptographically-Secure Pseudo-Random Number Generator (CSPRNG).
Are cryptographic operations timing-safe? Yes. All cryptographic operations are constant-time to prevent timing side-channel attacks.
Is cryptographic key material exposed to the application? No. Key material is not exposed at the application layer.
File Handling & Uploads
Where are uploaded files stored? Files from untrusted sources are stored in Amazon S3, outside the web root. Any transient server-side storage is also outside the web root. Files are never permanently stored on the web server itself.
Are uploaded files scanned for malware? Yes. All uploaded files are analyzed prior to acceptance to prevent storage or serving of malicious content.
Are uploaded SVG files sanitized?
Yes. User-uploaded SVG images are sanitized and sandboxed before use to prevent XSS via inline scripts or foreignObject.
Injection Prevention & Input Validation
How is JSON injection prevented?
JSON injection, eval() attacks, and JavaScript expression evaluation are explicitly blocked on all server and API interactions. Such attempts are treated as empty input.
How is LDAP injection handled? LDAP is not used by the application. All LDAP requests are denied.
How is SSRF (Server-Side Request Forgery) prevented? HTTP file metadata, filenames, and URL inputs are validated and sanitized on both client and server sides.
Is eval() or dynamic code execution used?
No. eval() is never used, and unsafe-eval is explicitly denied by our Content Security Policy.
How is output encoding handled? Output encoding is applied contextually — separate encoders are used for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, and other contexts as appropriate, including for untrusted inputs containing Unicode characters.
Anti-Automation & Rate Limiting
Is there protection against automated abuse? Yes. All API endpoints enforce rate limiting to protect against mass data exfiltration, denial-of-service attacks, and other automated abuse patterns.
Is there protection against HTTP parameter pollution? Yes. Our automated test suite attempts HTTP parameter pollution attacks on every development build. A failed test blocks deployment.
Application & Infrastructure Security
How is client-side code integrity verified? All components loaded from third-party sources include Subresource Integrity (SRI) hashes and are explicitly defined in our CORS configuration. No code is loaded from untrusted external sources at runtime.
How are DNS and subdomain takeovers prevented? All DNS entries are reviewed quarterly. No subdomains are dynamically or automatically created.
Are debug modes disabled in production? Yes. Automated deployment scripts ensure all debug settings are disabled before any release goes live.
How is sensitive data classified? All sensitive data is categorized into protection levels, each with associated encryption, integrity, retention, privacy, and confidentiality requirements applied throughout the architecture.
Is the application architecture documented? Yes. FluentCase maintains comprehensive documentation of all trust boundaries, components, and significant data flows, with justification for each architectural decision.
Secure Development & Testing
Is security testing automated? Yes. Security tests — including session expiration verification and HTTP parameter pollution testing — run as part of the automated test suite on every build. Failed security tests block deployment.
How are production deployments managed? Deployments are executed via automated scripts, but a human reviewer must validate automated test results before a release is permitted to proceed.
How quickly can the application be restored after a failure? Rollback of a failed deployment or re-deployment of a previous release can be completed using the same automated scripts in approximately 5–7 minutes.
How are third-party components managed? Source code and systems are regularly scanned for vulnerabilities. Patching and updates are performed based on those results. Third-party components loaded from external sources require SRI verification.