Data Security Practices

How Exposure protects your data, content, and privacy

Overview

Exposure takes the security of your data seriously. This article outlines the practices we employ to protect user accounts, payment information, uploaded content, and personal data across our platform.

Infrastructure & Network Security

Hosting

Exposure is hosted on Amazon Web Services (AWS) using Elastic Container Service (ECS). AWS infrastructure is certified across multiple compliance standards, including SOC 1/2/3, ISO 27001, and PCI DSS Level 1.

Our production, staging, and development environments are fully isolated with separate credentials, encryption keys, and database instances.

DNS & Edge Security

All DNS is managed through Cloudflare, with the full suite of security features enabled:

Cloudflare SSL/TLS provides end-to-end encryption for all traffic, including custom domains
Cloudflare DDoS protection automatically detects and mitigates volumetric and application-layer attacks
Web Application Firewall (WAF) filters malicious traffic before it reaches our servers
Bot Management identifies and blocks automated threats at the edge
DNSSEC is enabled to prevent DNS spoofing and cache poisoning attacks
Always Use HTTPS ensures all requests are upgraded to secure connections

Custom domain users benefit from Cloudflare-issued SSL certificates, providing the same level of encryption and protection as the primary Exposure domain.

Encryption in Transit

All data transmitted between your browser and Exposure is encrypted via TLS/HTTPS
SSL is enforced at both the Cloudflare edge and infrastructure layer across all endpoints
Static assets are served through Amazon CloudFront over HTTPS

DDoS & Abuse Protection

Cloudflare DDoS mitigation provides always-on protection at the network edge
Rate limiting is enforced across critical endpoints including authentication, contact forms, and data exports
An IP blocklist system enables rapid response to identified threats
Request timeout protection prevents resource exhaustion attacks

Data Encryption

Encryption at Rest

Sensitive fields stored in our database are encrypted using AES-256-GCM encryption. This includes story passwords and third-party access tokens. Account sign-in passwords use one-way hashing, as described below.

All application secrets, API keys, and service credentials are stored in encrypted credential files protected by environment-specific master keys. These keys are managed through secure environment variables and are never committed to source code.

Password Security

User passwords are hashed using bcrypt, a one-way adaptive hashing algorithm. Plaintext passwords are never stored or logged.
The password form requires at least eight characters. Use a unique password for your Exposure account.
Password-reset links use random tokens, stored as digests. A reset link expires after 30 minutes, works once, and is replaced when you request another link. Resetting a password does not remove two-factor authentication.

Payment Security

PCI DSS Compliance

Exposure uses Stripe for all payment processing. Stripe is a PCI DSS Level 1 certified service provider, the highest level of payment security certification.

No credit card numbers, CVVs, or full card details are ever transmitted to, processed by, or stored on Exposure servers.

Here’s how it works:

Payment information is tokenized entirely on the client side using Stripe.js
Stripe returns references that our servers use to verify the setup and manage billing
We store Stripe references, verification status, and a record of your consent. Billing screens can display limited card details, such as its brand and last four digits
All billing operations are handled directly through Stripe’s secure API

Card verification at signup does not create a charge or start a paid subscription.

Webhook Verification

Incoming payment events from Stripe are validated before processing. Subscription status is verified against Stripe’s API before any access changes are made to your account.

Authentication & Access Control

Account Authentication

Authentication uses server-side sessions. A browser cookie identifies the session, which has a two-week expiry.
Sign-in and security checks have attempt limits. Repeated failures can temporarily block verification; the message on the screen explains the next step.
Google reCAPTCHA Enterprise is required during account registration to prevent automated abuse

Members can sign up or sign in with Google and manage the connection in Settings → Security & Signin. Exposure verifies the Google identity on the server. It stores the Google account identifier and verified email, but does not retain Google access or refresh tokens.

Verified Gmail and Google Workspace emails can connect automatically to matching confirmed Exposure accounts. Existing two-factor checks apply before a new connection is saved. Other addresses use the manual connection flow. Connecting or disconnecting Google ends older sessions and sends a security email. A member must add a password before removing their only sign-in method.

See Sign in to your Exposure account.

Two-factor authentication

Members can opt in to two-factor authentication in Settings → Security & Signin. It is required for Exposure staff accounts. Enabling the option for members does not turn it on automatically for each account.

After setup, sign-in requires a password or connected Google account, followed by a six-digit code from an authenticator app, or one unused recovery code. Exposure provides ten recovery codes at setup. Authenticator secrets are encrypted, and recovery codes are stored as digests. A successfully used code cannot be reused.

Resetting a password does not remove 2FA. Changing or turning off the authenticator requires the current password and an authenticator or recovery code. Members without an Exposure password verify with their connected Google account instead of a password; the code check still applies. Creating new recovery codes replaces the old set. These security changes invalidate older sessions for the account.

If both the authenticator and recovery codes are lost, contact support. Email access alone does not remove 2FA, and account recovery is not guaranteed. This account protection does not by itself establish regulatory compliance or certification.

See Set up and manage two-factor authentication and Use and replace recovery codes.

Session Security

Sessions are stored server-side, minimizing data exposed in cookies
Production session cookies use Secure, HttpOnly, and SameSite=Lax attributes.
Signing out ends the selected session access. Password, email, authenticator, and recovery-code changes invalidate older sessions for that account.

CSRF Protection

Cross-Site Request Forgery protection is enabled across the entire application. External integrations such as payment webhooks use alternative authentication mechanisms (signature verification, token authentication) in place of CSRF tokens.

Application Security

Input Validation

All user input is validated server-side, including format checks, length limits, and uniqueness constraints
Email addresses are validated using a dedicated library and checked against a blocklist of disposable email providers
File uploads are restricted to allowed image types (PNG, GIF, JPEG) with enforced size limits

Injection Prevention

SQL injection is prevented through the exclusive use of parameterized database queries. No raw SQL with string interpolation is used anywhere in the application.
Cross-Site Scripting (XSS) is mitigated through automatic HTML output escaping in all templates

Bot & Spam Protection

Contact forms and subscription forms use multi-layered protection, including:

Honeypot fields to catch automated bots
Submission timing analysis
Content-based spam filtering
reCAPTCHA Enterprise score-based verification
Rate limiting on both burst and sustained submission patterns

Data Privacy & Retention

Data Minimization

Exposure collects only the information necessary to provide the service: your name, email, username, and optional profile fields. Payment credentials are managed entirely by Stripe.

Account Deletion

You can delete your account at any time from your account settings. Deletion follows a two-stage process:

Immediate soft delete - Your account is removed from all public queries, email preferences are cleared, and your content is no longer accessible
Permanent purge - After a grace period, all associated data is permanently and irreversibly deleted, including stories, photos, email subscribers, Stripe subscriptions, and all cached data

Automatic Cleanup

Expired sessions are purged daily via scheduled background jobs
Stale push notification subscriptions are cleaned up on a daily schedule

Data Export

You can export your email subscriber lists via CSV download at any time.

Secure Development Practices

The codebase follows Rails security best practices, including parameterized queries, CSRF protection, automatic output escaping, and encrypted credentials
Brakeman (static security analysis) is used to identify potential vulnerabilities
Bundler Audit scans dependencies for known security vulnerabilities
Strong Migrations prevents unsafe database changes that could cause data loss
Sensitive parameters (passwords, tokens, keys) are automatically filtered from all application logs

Third-Party Services

Exposure integrates with trusted, security-certified third-party services:

Service	Purpose	Compliance
Cloudflare	DNS, SSL, WAF & DDoS protection	SOC 2 Type II, ISO 27001, PCI DSS Level 1
Amazon Web Services	Infrastructure & file storage	SOC 1/2/3, ISO 27001, PCI DSS Level 1
Stripe	Payment processing	PCI DSS Level 1
Postmark	Transactional email	SOC 2 Type II
Google reCAPTCHA	Bot protection	Google Cloud security standards
Datadog	Performance monitoring	SOC 2 Type II, ISO 27001
OpenRouter	AI model gateway for alt text and cover video captions	Routes requests only to zero-data-retention endpoints
Google Cloud Vertex AI	AI models for alt text and cover video captions	Google Cloud security standards, zero data retention
Amazon Bedrock	AI model for short alt text	SOC 1/2/3, ISO 27001, zero data retention

All API keys and credentials for third-party services are stored in encrypted credential files and are never exposed in source code or logs.

The AI providers do not keep the content of requests and may not use it to train AI models. See How Exposure uses AI.

Content Security

Uploaded photos are stored in Amazon S3 with access managed through AWS IAM policies
All content is served over HTTPS through a CDN
Unpublished, password-protected, and deleted content is excluded from all public queries and endpoints
Story-level and site-level password protection allow you to restrict access to your content. These passwords are encrypted at rest.

Monitoring

Application performance monitoring provides real-time alerting in production
Background job processing is monitored for failures and queue health
All requests are tagged with unique IDs for traceability
Production logging operates at a level that minimizes inadvertent exposure of personal information

Need Help?

If you have questions about our security practices, reach out to us at support@exposure.co. We’re happy to help!

Need help?

Use the Exposure contact form.