Ephemeral

Security Policy

Last updated: February 18, 2026

Security Overview

Security is not an afterthought at Ephemeral—it's the foundation of everything we build. Our service is designed from the ground up with a zero-trust architecture and privacy by design principles.

End-to-End Encrypted
Auto-Destructing
Zero-Knowledge
TLS 1.3

Encryption

Encryption at Rest

All secrets are encrypted using industry-standard authenticated encryption algorithms:

Algorithm Standard Use Case
XSalsa20-Poly1305 NaCl/Sodium Default encryption (high performance)
AES-256-GCM NIST SP 800-38D, FIPS 140-2 HIPAA/SOC2 compliance environments

Key Management

  • Unique Keys: Every secret has its own unique encryption key pair.
  • Key Separation: Encryption keys are stored separately from encrypted content.
  • Automatic Deletion: Keys are destroyed when the secret is viewed or expires.
  • No Key Recovery: We cannot recover or regenerate encryption keys.

Encryption in Transit

  • All connections use TLS 1.3 with modern cipher suites.
  • HTTP Strict Transport Security (HSTS) is enforced.
  • Certificate Transparency logs are monitored.
Zero-Knowledge Design

Even if our systems were compromised, attackers could not read your secrets. The encryption keys are stored separately and deleted after use.

Security Architecture

Dual Storage Model

We use a split-storage architecture for defense in depth:

Key Storage

Encryption keys stored in volatile memory (Redis) with automatic expiration. No persistence to disk.

Secret Storage

Encrypted content stored in object storage (S3-compatible). Useless without corresponding keys.

Atomic Operations

Secret retrieval uses atomic operations (GETDEL) to ensure that secrets can only be viewed once. This prevents race conditions where multiple requests could access the same secret.

Password Protection

  • Optional password protection uses Argon2id hashing (winner of the Password Hashing Competition).
  • Parameters: 64MB memory, 4 iterations, 1 parallelism.
  • Rate limiting prevents brute-force attacks (5 attempts per 15 minutes).

Data Protection

Data Minimization

  • We collect only what's necessary to provide the service.
  • IP addresses are hashed before storage.
  • No user accounts or persistent identifiers.
  • Secrets auto-delete after viewing or TTL expiration.

Data Lifecycle

Data Type Retention Deletion Trigger
Encrypted secrets Maximum 30 days Viewed or TTL expires
Encryption keys Same as secret Deleted with secret
Audit logs 30 days Automatic rotation
Session data Browser session Browser close

Access Control

Rate Limiting

We implement multiple layers of rate limiting to prevent abuse:

Action Limit Window
Secret creation 10 requests 1 hour
Secret reveal 20 requests 1 hour
Password attempts 5 attempts 15 minutes

Security Headers

All responses include security headers:

  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY
  • X-XSS-Protection: 1; mode=block
  • Referrer-Policy: strict-origin-when-cross-origin
  • Content-Security-Policy (restrictive policy)

Security Monitoring

Audit Logging

We maintain comprehensive audit logs for security events:

  • Secret creation (timestamp, TTL, password-protected flag)
  • Secret access attempts (success/failure)
  • Rate limit triggers
  • Authentication failures

Privacy Note: Logs never contain secret content. IP addresses are hashed. See our Privacy Policy for details.

Automated Security Scanning

Our CI/CD pipeline includes automated security checks:

Dependency Scanning

Composer Audit and Dependabot for vulnerability detection in dependencies.

SAST

Semgrep static analysis for OWASP Top 10 vulnerabilities.

Container Scanning

Trivy scans Docker images for CVEs before deployment.

Secret Detection

Gitleaks prevents accidental commit of credentials.

Incident Response

Response Process

  1. Detection: Automated monitoring and user reports.
  2. Triage: Assess severity and impact within 1 hour.
  3. Containment: Isolate affected systems immediately.
  4. Investigation: Determine root cause and scope.
  5. Remediation: Fix vulnerability and restore service.
  6. Notification: Inform affected users per legal requirements.
  7. Post-Mortem: Document lessons learned.

Notification Timeline

  • GDPR: 72 hours to supervisory authority for personal data breaches.
  • Users: Without undue delay for high-risk breaches.
Transparency Commitment

In the event of a security incident, we commit to transparent communication with affected users and will publish a post-mortem for significant incidents.

Vulnerability Disclosure

Responsible Disclosure Policy

We welcome security researchers to help us keep Ephemeral secure. If you discover a vulnerability, please report it responsibly.

How to Report

  1. Email security@ephemeral.example.com
  2. Include detailed steps to reproduce
  3. Provide proof-of-concept if possible
  4. Allow us reasonable time to respond (72 hours initial response)

What to Report

  • Authentication or authorization bypasses
  • Cryptographic weaknesses
  • Cross-site scripting (XSS)
  • SQL injection or other injection attacks
  • Information disclosure
  • Denial of service vulnerabilities

Safe Harbor

We will not pursue legal action against security researchers who:

  • Act in good faith
  • Avoid privacy violations and data destruction
  • Do not exploit vulnerabilities beyond proof-of-concept
  • Give us reasonable time to remediate before disclosure
Recognition

We acknowledge security researchers in our Hall of Fame (with permission) for valid vulnerability reports.

Compliance

Our security practices align with industry standards and regulations:

Standard Status Notes
GDPR Compliant Privacy by design, data minimization
CCPA Compliant No data selling, deletion rights
SOC 2 Ready Controls implemented, audit pending
HIPAA Ready AES-256-GCM available, BAA on request
OWASP Top 10 Mitigated Automated SAST scanning

Security Contact

For security-related inquiries:

PGP Key Available on request for encrypted communications

Response time: Initial response within 72 hours for security reports.