critical priority high complexity testing pending testing specialist Tier 11

Acceptance Criteria

Test encrypts a blob with Org A's key and asserts that attempting decryption with Org B's key throws DecryptionException or returns null
Test modifies a single byte in an encrypted blob and asserts that decryption/verification throws TamperDetectedException
Test generates a signed URL with a short TTL (e.g., 2 seconds), waits for expiry, and asserts HTTP 400/403 is returned on access
Test using Org B's authenticated Supabase Storage client attempts to read a file in Org A's storage bucket path and receives HTTP 403
Test using Org B's authenticated client attempts to upload to Org A's storage path and receives HTTP 403
All encryption key material is org-specific and cannot be reconstructed from public data
A findings document is produced listing each test, its result (pass/fail), and remediation taken for any failure
Zero security test failures remain unresolved before task is marked complete
Tests are repeatable and runnable in CI without manual steps

Technical Requirements

frameworks
flutter_test
Dart
Supabase
apis
Supabase Storage API
Supabase Auth API
DeclarationEncryptionService internal API
data models
EncryptedBlob
Organization
StorageObject
performance requirements
Signed URL expiry test must tolerate up to 1 second clock skew between client and Supabase server
Each security test completes within 10 seconds
security requirements
Org encryption keys must never appear in test logs or error messages
Tests must use real Supabase RLS — no service role bypass for negative-path assertions
Tamper detection must use HMAC or AEAD (e.g., AES-GCM) — assert the authentication tag is verified
Test credentials stored in environment variables, never hardcoded
Signed URL TTL tests must use wall-clock sleep, not mocked time, to validate real server-side expiry

Execution Context

Execution Tier
Tier 11

Tier 11 - 5 tasks

Can start after Tier 10 completes

Implementation Notes

For the tamper detection test, flip a single bit in the ciphertext body (not the IV or tag) to simulate a realistic tampering scenario — this is the most common attack vector. For signed URL expiry, use a 2-second TTL and a 3-second sleep to account for clock skew; avoid 1-second TTL as it causes flakiness. For cross-org storage RLS tests, create two Supabase sessions using email/password auth for two different test users assigned to different orgs. Supabase Storage bucket policies must be configured to enforce org_id path prefix matching — validate this configuration is in place as a prerequisite.

If AES-GCM is used for encryption, the authentication tag verification happens automatically on decrypt — catch the AesGcmException. Document the encryption algorithm, key derivation method, and IV strategy in findings.md regardless of pass/fail.

Testing Requirements

Security-focused integration tests using flutter_test against a real Supabase test project. Do not mock encryption or storage. Test cases must cover: (1) cross-org key isolation (encrypt with A, decrypt attempt with B), (2) tamper detection (mutate ciphertext, expect rejection), (3) signed URL TTL expiry (real sleep, real HTTP request), (4) Supabase Storage RLS cross-org read rejection, (5) Supabase Storage RLS cross-org write rejection. Produce a findings.md document alongside the test file recording each scenario, expected result, actual result, and remediation status.

All tests must be green before closing this task.

Component
Declaration Encryption Service
service high
Epic Risks (4)
high impact medium prob security

Org-scoped encryption key management is complex. If keys are not correctly isolated per organization, a breach in one org's key could expose another org's declarations. Additionally, key rotation is not specified but may be needed for compliance, and the current implementation may not support it.

Mitigation & Contingency

Mitigation: Use Supabase Vault or a dedicated secrets management approach for org-scoped key storage. Define the key derivation strategy (per-org master key) in a security design document reviewed before implementation begins. Include key isolation tests in the test suite.

Contingency: If a full per-org key management system cannot be safely implemented within the sprint, fall back to a single platform-level encryption key with strict RLS isolation as a temporary measure, flagging the key rotation gap as a security debt item with a defined resolution milestone.

medium impact medium prob integration

Push notification delivery to drivers depends on FCM token availability and device connectivity. If a driver has not granted notification permissions or has an expired FCM token, the declaration delivery notification will silently fail, leaving the coordinator unaware and the declaration unacknowledged.

Mitigation & Contingency

Mitigation: Implement delivery status tracking in declaration-notification-service. Fall back to in-app notification and SMS (if configured) when push delivery fails. Expose delivery failure status in the declaration status badge so coordinators can identify and manually follow up.

Contingency: If push delivery proves unreliable, implement a polling-based in-app notification fallback where drivers see pending declarations on next app open, ensuring the workflow can complete even without push notifications.

medium impact medium prob technical

The acknowledgement service is meant to validate that the driver has fully scrolled through the declaration before confirming. Implementing reliable scroll completion detection in Flutter across different screen sizes and font sizes is technically non-trivial and could be bypassed.

Mitigation & Contingency

Mitigation: Implement scroll position tracking using ScrollController with a threshold (e.g., 95% of content height reached) and record the validated state server-side before allowing acknowledgement submission. Document the approach in the legal sign-off checkpoint noted in the feature documentation.

Contingency: If reliable scroll detection cannot be implemented within the sprint, add a mandatory reading delay timer (e.g., estimated reading time based on word count) as an alternative validation mechanism, pending legal review of the approach.

medium impact low prob dependency

The driver assignment service must coordinate with the threshold-based expense approval workflow for fees above configured thresholds. If the expense approval workflow interface changes or is not yet stable, the integration point could break or produce incorrect routing behavior.

Mitigation & Contingency

Mitigation: Define a clear interface contract between driver-assignment-service and the expense approval workflow before implementation. Use dependency injection so the expense workflow client can be mocked in tests. Monitor the expense approval feature for interface changes.

Contingency: If the expense approval workflow interface is not stable, implement a direct database insert to the expense records table as a temporary bypass, with a flag indicating manual review is needed, until the stable interface is available.