Security Architecture & Cryptographic Design

1. Executive Summary

fetchOnce is a zero-knowledge, one-time secret sharing service. It enables the secure transmission of sensitive credentials, tokens, and confidential data between parties without exposing that data to any server, intermediary, or network observer.

The central security property of fetchOnce is architectural rather than procedural: the server is mathematically incapable of reading stored secrets. Encryption is performed exclusively in the sender's browser using browser-native cryptographic APIs before any data transits the network. The decryption key is never transmitted to the server under any circumstances. The server stores only opaque ciphertext it cannot interpret.

Upon retrieval, the secret is atomically deleted from persistent storage in the same database transaction that returns the ciphertext to the authorised recipient. The deletion is immediate, permanent, and unrecoverable. There is no soft-delete, no backup retention of secret content, and no administrative pathway to retrieve a revealed secret.

This architecture eliminates an entire class of server-side data breach risk. A fully compromised server yields no usable plaintext. The cryptographic guarantee holds regardless of the operational security posture of the infrastructure.

2. Threat Model

2.1 Assets Under Protection

The primary asset is the plaintext secret content provided by the sender: passwords, API keys, private tokens, access credentials, and similar sensitive values. Secondary assets include metadata that could reveal usage patterns, though fetchOnce is designed to minimise even this.

2.2 Threat Actors Considered

2.3 Out-of-Scope Threats

fetchOnce does not protect against: compromise of the sender's or recipient's device; keyloggers or malicious browser extensions on either endpoint; social engineering of the recipient; or interception of the out-of-band channel used to transmit the link. These threats are outside the scope of any server-side security control.

3. Cryptographic Architecture

3.1 Encryption Algorithm

All secret content is encrypted using AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode). AES-GCM is an authenticated encryption with associated data (AEAD) scheme that simultaneously provides:

• Confidentiality — the plaintext cannot be recovered without the key
• Integrity — any modification to the ciphertext causes decryption to fail unconditionally
• Authenticity — the 128-bit authentication tag verifies the ciphertext was produced by the holder of the key

AES-256-GCM is the authenticated encryption standard recommended by NIST SP 800-38D and is approved under FIPS 140-2. It is the same algorithm used to secure TLS 1.3 connections.

3.2 Key Generation

A unique 256-bit AES key is generated for every secret using the browser's crypto.getRandomValues() API, which sources entropy from the operating system's cryptographically secure pseudorandom number generator (CSPRNG). No two secrets share a key. Keys are generated entirely within the sender's browser and are never transmitted to any server.

3.3 Initialisation Vector

Each encryption operation uses a fresh 96-bit (12-byte) initialisation vector (IV), also generated via crypto.getRandomValues(). The IV is prepended to the ciphertext before storage. GCM mode with a 96-bit IV is the NIST-recommended configuration and provides the strongest security guarantees for that mode.

3.4 Implementation

All cryptographic operations are performed using the browser's native Web Crypto API (window.crypto.subtle). No third-party cryptographic libraries are used. The Web Crypto API is implemented natively by the browser vendor and is not subject to supply chain attacks on JavaScript dependencies.

4. Key Management & Distribution

4.1 Key Confinement

The encryption key exists only in the sender's browser memory during the creation flow and in the recipient's browser memory during the reveal flow. It is never written to disk, never stored in browser storage (cookies, localStorage, sessionStorage, IndexedDB), and never transmitted to any server.

4.2 Key Distribution via URL Fragment

The key is encoded in base64url format and appended to the secret link as the URL fragment — the portion of the URL following the # character. URL fragments are explicitly excluded from HTTP request transmission by the HTTP/1.1 specification (RFC 7230) and all subsequent versions. Browsers do not include the fragment in the request URI sent to the server. The key therefore does not appear in:

• Server access logs
• Reverse proxy logs
• Network capture at the server
• CDN or load balancer logs
• Referrer headers on outbound navigation

4.3 Key Lifetime

The key is ephemeral. Once the recipient's browser has successfully decrypted the secret, the key has no further utility. The server-side record has been deleted. The key material in browser memory is garbage collected when the page is closed. No persistent copy of the key exists in any system under fetchOnce's control.

5. Data Lifecycle & Retention

5.1 What Is Stored

fetchOnce stores the minimum data necessary to operate the service:

Key names, secret values, sender identity, recipient identity, and IP addresses are not stored in association with secret records.

5.2 Reveal & Deletion

When a recipient reveals a secret, the server executes a single atomic database transaction that reads the ciphertext and deletes the record. These two operations are not separable: there is no system state in which the ciphertext has been returned to a client but the record has not been deleted. A second request for the same secret ID returns HTTP 404 unconditionally.

5.3 Expiry

Each secret carries an expiration timestamp set at creation time, between one hour and seven days. A background process periodically sweeps for expired records and deletes them permanently. An expired secret cannot be retrieved, revealed, or recovered by any means.

5.4 Deletion Permanence

Deleted records are not retained in any backup, recycle bin, or soft-delete state. There is no administrative interface through which a deleted secret may be recovered. The deletion is final.

6. Transport Security

All traffic between clients and the fetchOnce service is protected by TLS 1.2 or higher, with TLS 1.3 preferred. The following HTTP security headers are enforced on all responses:

7. Infrastructure Security

7.1 Reverse Proxy Architecture

The application tier communicates with the reverse proxy over a Unix domain socket rather than a TCP network interface. This eliminates the network attack surface between the proxy and application layers entirely. The application process is not reachable from any network interface directly.

7.2 Container Hardening

The application runs inside a minimal Alpine Linux container built using a multi-stage Docker build. The runtime image contains no compiler, no build toolchain, no package manager, and no shell utilities beyond what is strictly required for operation. Specific hardening measures include:

• Process runs as a dedicated non-root user with no login shell
• Application source files are mounted read-only (chmod 444)
• dumb-init serves as PID 1, ensuring correct signal propagation and zombie process reaping
• Container resource limits constrain memory and CPU consumption

7.3 Dependency Management

All container images are scanned for known vulnerabilities using Trivy prior to deployment. Images containing HIGH or CRITICAL severity CVEs with available fixes are blocked from deployment automatically. Base images are pinned to specific Alpine Linux versions to prevent supply chain substitution.

7.4 Deployment Pipeline

All code changes are deployed through an automated CI/CD pipeline that enforces the following gate sequence: build, vulnerability scan, database migration, deployment. No code reaches production without passing each gate. Database schema changes are applied atomically via Alembic migrations before the new application version receives traffic.

8. Application-Level Controls

8.1 CSRF Protection

All state-mutating endpoints (secret creation and revelation) require a valid Cross-Site Request Forgery token. Tokens are HMAC-SHA256 signed with a server-side secret, include a random nonce and an embedded timestamp, and expire after one hour. Validation uses constant-time comparison to prevent timing oracle attacks. Tokens are single-use in practice, as each page load generates a fresh token.

8.2 Rate Limiting

A per-IP sliding window rate limiter is applied to all creation and reveal endpoints. Requests exceeding the threshold receive HTTP 429 with a Retry-After header. The limiter includes a periodic sweep to remove stale entries, preventing unbounded memory growth under sustained attack traffic.

8.3 Input Validation

All API inputs are validated against typed Pydantic schemas before processing. Encrypted payload size is bounded to prevent storage exhaustion. Secret IDs are validated against an allowlist pattern before database lookup to prevent injection attacks.

8.4 Request Correlation

Every request is assigned a unique X-Request-ID that propagates through all log entries for that request. This enables forensic correlation of related log events across the application and proxy layers without requiring any identifying user data.

9. Privacy & Data Minimisation

fetchOnce is designed around the principle of data minimisation. The service collects no personally identifiable information about senders or recipients. Specifically:

• No user accounts, registration, or authentication is required
• No cookies are set on any client
• No analytics, telemetry, or tracking mechanisms are employed
• IP addresses are present in operational access logs but are not correlated with or stored alongside secret records
• The only third-party resource loaded is Google Fonts for typography, subject to Google's standard privacy policy

Because the service stores no personal data associated with individuals, data subject access requests, right-to-erasure requests, and similar GDPR/CCPA obligations are straightforwardly satisfied: there is no personal data to return or delete.

10. Compliance Considerations

The tables below map fetchOnce's implemented controls to the requirements of major security and compliance frameworks. fetchOnce has not undergone formal third-party audit against any of these frameworks. The mappings represent design alignment and are provided to assist evaluators in determining applicability to their compliance programmes.

10.1 SOC 2 Type II — Trust Services Criteria

SOC 2 evaluates controls across five Trust Services Criteria categories. The following criteria are relevant to a zero-knowledge secret transmission service:

10.2 NIST SP 800-53 Rev 5

NIST SP 800-53 is the US federal information security control catalogue, forming the basis of FedRAMP. The following control families are relevant to fetchOnce's architecture:

10.3 HITRUST CSF v11

The HITRUST Common Security Framework is widely adopted in healthcare and financial services. The following control categories are relevant to fetchOnce:

10.4 FedRAMP Baseline Alignment

FedRAMP applies NIST SP 800-53 controls at Low, Moderate, and High impact baselines for US federal cloud services. fetchOnce has not undergone FedRAMP authorisation. The table below indicates alignment of implemented controls with each baseline level for the relevant control families:

Agencies considering fetchOnce for Low or Moderate impact workloads should conduct an independent assessment against the full applicable control baseline. High impact workloads require formal FedRAMP authorisation with a third-party assessment organisation (3PAO).

10.5 GDPR

fetchOnce does not act as a data processor in the GDPR sense with respect to secret content, because it never has access to that content. The service processes only the ciphertext, which is not personal data within the meaning of GDPR Article 4(1) as it cannot be attributed to an identifiable natural person by fetchOnce or any party without the key.

10.6 HIPAA

Organisations subject to HIPAA should evaluate whether transmitting protected health information via fetchOnce is appropriate for their compliance posture. The zero-knowledge architecture means fetchOnce cannot read, use, or disclose PHI stored through the service. However, formal HIPAA BAA coverage and independent compliance assessment are the responsibility of the covered entity.

11. Responsible Disclosure

fetchOnce welcomes responsible disclosure of security vulnerabilities. If you identify a potential security issue, please report it to the address listed in our security.txt file. We commit to acknowledging reports promptly and working in good faith toward resolution before public disclosure.

We ask that you do not publicly disclose vulnerability details before we have had a reasonable opportunity to investigate and respond, and that you do not exploit any identified vulnerability against live user data.

Appendix: Cryptographic Primitive Reference

Document version 1.1 — April 2026. This document is reviewed annually or upon material changes to the security architecture or compliance framework mappings. For the current version, visit fetchonce.com/whitepaper. © 2026 fetchOnce 🐾 All rights reserved.