Encryption in transit
Last updated: Nov 3, 2026
All the applications and services of Fluid Attacks have industry-standard encryption in transit.
- The Fluid Attacks domain accepts only TLSv1.3 end-to-end. Cloudflare proxies each zone in Strict mode. The edge verifies the origin certificate on each backend hop. Thus, no part of the connection goes back to plaintext or to an unverified upstream. This screenshot shows the SSL configuration of Fluid Attacks.

- Origins authenticate Cloudflare cryptographically through Authenticated Origin Pulls (mTLS) with a private CA. The TLS layer rejects TLS handshakes that do not have a leaf certificate signed by this CA, before they get to the application.
- Each TLS handshake on the public data path uses the X25519MLKEM768 hybrid post-quantum key exchange (X25519 combined with NIST-standardized ML-KEM-768). The hybrid design stops the "harvest-now, decrypt-later" attack. A network observer who records a handshake today must break the classical component and the lattice-based component to recover the session key. This is true if the observer has a future quantum computer too.
- Fluid Attacks submitted the three primary zones
(
fluidattacks.com,fluidattacks.tech,fluidattacks.org) to the browser-baked HSTS preload list. Thus, modern browsers refuse plaintext HTTP to these zones on the first request, before data leaves the device. The hstspreload.org public API shows the live status: - Fluid Attacks uses short-lived digital certificates that renew automatically.
The certificate of
fluidattacks.comis valid for 14 days. - All connections must support a minimum of TLSv1.2.
- The database of the platform uses TLSv1.2 to protect data in transit.
- Fluid Attacks has fully dedicated network channels with some of its largest clients. With these channels, Fluid Attacks isolates all unwanted traffic. This is very useful for secure dynamic application testing.
- For its other clients, Fluid Attacks uses fully encrypted VPNs.
- Fluid Attacks keeps an SSL A+ score from SSL Labs. The profile of Fluid Attacks has an updated report. This screenshot shows the score.

Data-path enforcement
Each hop of the public data path has transport encryption and an explicit identity check on the receiving side:
| Hop | TLS | Key exchange | Origin authentication |
| Browser → Cloudflare | TLS 1.3 | X25519MLKEM768 | HSTS preload (first-contact) |
Cloudflare → ALB (app.*) | TLS 1.3 | X25519MLKEM768 | mTLS (AOP, private CA) |
Cloudflare → CloudFront (*.com) | TLS 1.3 | X25519MLKEM768 | mTLS (AOP, private CA) |
| ALB → backend pod | TLS 1.3 | X25519MLKEM768 | (VPC-internal) |
| CloudFront → S3 origin | TLS, SigV4 | (AWS-managed) | CloudFront OAC |
| CloudFront → Lambda Function URL | TLS, SigV4 | (AWS-managed) | CloudFront OAC |
Framework mapping
The controls on this page satisfy these compliance framework requirements:
- PCI-DSS 4.0 Req 4.2.1: Strong cryptography for sensitive data in transit over open networks. These controls satisfy it: the TLS 1.3 floor, Strict mode end-to-end, AOP mTLS at origins, and HSTS preload for first-contact requests.
- SOC2 Trust Services Criterion CC6.7: Restriction of information transmission to authorized users and processes. The same controls satisfy it, together with origin authentication. Origin authentication rejects traffic that does not come from Cloudflare at the TLS layer, before it gets to the application.
Requirements
These Fluid Attacks requirements apply to the controls on this page:
- 092. Use externally signed certificates
- 147. Use pre-existent mechanisms
- 181. Transmit data using secure protocols
- 336. Disable insecure TLS versions
Other confidentiality measures
Encryption at rest
Fluid Attacks protects sensitive data using AES-256 GCM encryption, KMS-managed secrets, and full-disk encryption (BitLocker, LUKS, FileVault) in all devices.
Logical data separation
Fluid Attacks enforces logical data separation between clients at both the database and application authorization layers.