Security

This page describes how we protect Atlas and the data on it. It is written to be specific and honest: we list the controls we actually have in place today and, at the bottom, the ones we do not have yet. If a claim here ever stops being true, that is a bug — please tell us at [email protected].

Overview

Atlas is a small team building a location-based storytelling platform. Location data is more sensitive than most things people post online, so we treat security as a product feature rather than a compliance checkbox. The core principles:

• Least privilege. Every service, credential, and human account gets the narrowest access it needs.
• Fail closed. When a permission check is ambiguous, we deny by default and fix the code, not the policy.
• No advertising, no third-party trackers. Your data is not a product we sell. This is enforced in code, not just in policy — see the Cookie Policy.

Encryption in transit

Every connection to onatlas.world and to our API is served over HTTPS with a modern TLS configuration (TLS 1.2+). We enable HSTS on the marketing and app domains, so browsers refuse plaintext connections after the first visit. The iOS app pins to the same certificate chain.

Traffic between our web servers, workers, database, cache, and object storage stays inside private networking on the hosting provider — it does not traverse the public internet.

Encryption at rest

The Postgres database and the S3 bucket that stores uploaded media are encrypted at rest by the hosting provider using AES-256. Nightly database backups are encrypted with the same standard. Passwords are stored as bcrypt hashes (cost factor 12); we never see, log, or transmit the plaintext.

Hosting & infrastructure

The web application, workers, and database run on DigitalOcean in the Frankfurt region. Uploaded media is stored in AWS S3 and served through Amazon CloudFront. Both providers are SOC 2 Type II certified.

The web tier runs as multiple instances behind a load balancer, so deploys are zero-downtime and a single instance failure does not take the site down. The database uses a connection pooler (PgBouncer) so a traffic spike cannot exhaust the connection limit.

Access control

Production access is limited to a small number of engineers on the team. Everyone with production access uses hardware-backed two-factor authentication on the hosting provider, on GitHub, on Google Workspace, and on their laptop. There are no shared credentials — every action in production traces back to a specific person.

Admin actions performed inside the app (approving accounts, resolving reports, deleting content) are written to an append-only audit log that survives even if the admin user account is later deleted.

Secrets & credentials

Application secrets — database URLs, API keys for AWS, Google Maps, SendGrid, Sentry, Apple Sign-In, JWT signing keys — live in the hosting provider's secret store, scoped per-environment and never committed to source control. Local development uses a separate set of keys and a separate database.

JSON Web Tokens issued to the mobile app are signed with a rotated secret; a compromise of a JWT is capped to the token's lifetime and can be forcibly invalidated by the account owner via Sign out all devices.

Account authentication

Users sign in with one of:

• Sign in with Google — Atlas never sees your Google password.
• Sign in with Apple — Atlas never sees your Apple password. Revoking access from your Apple ID settings signs you out of Atlas.
• Email + password — bcrypt-hashed, with rate limiting on failed attempts and email notifications on suspicious sign-ins.

Session cookies are HTTP-only, Secure, and SameSite=Lax, so they cannot be read by JavaScript and are not sent on cross-site requests. Mobile devices store the auth token in the platform's secure enclave (iOS Keychain).

Private media & privacy

Uploaded media (photos and video) is served through one of two tiers, decided per-file by whether the media appears in a published, public story:

• Public media — served through CloudFront with a public URL. Faster and cache-friendly. Used only when the media is intentionally shared to the whole internet.
• Private media — served through an authenticated proxy that fetches the file from a private S3 bucket and streams it to the requester after verifying their permission to see it. Fails closed: an unauthenticated request returns 404 (never a redirect that leaks the underlying URL).

Flipping a story from public to private synchronously re-evaluates every attached media file and moves it to the private tier. A daily reconciler sweeps the database as a safety net in case any code-path missed the flip.

Backups & durability

The primary Postgres database is backed up nightly by the hosting provider, retained for seven days, and stored in a separate region. Point-in-time recovery is available for the last 24 hours. Media objects in S3 are stored across multiple availability zones with 11 9s of durability, and the bucket has versioning enabled so a deleted object can be restored during the retention window.

We test the restore path periodically by spinning up a scratch database from the latest backup and running the app against it. A backup you have not restored from is a hope, not a plan.

Monitoring & error visibility

The web application, workers, mobile app, and admin dashboard all report unhandled errors and slow transactions to Sentry, with personally identifying fields scrubbed at the SDK boundary before they leave the device. Every request is tagged with a request ID that a support agent can trace end-to-end without needing to reproduce the bug.

A small set of health checks (database ping, Redis ping, storage reachability) runs on a schedule and pages the on-call engineer if anything degrades. The client-side Sentry SDK only initializes if the user has accepted analytics cookies — see the Cookie Policy.

Subprocessors

The following third parties process user data on Atlas's behalf. Each is bound by a data processing agreement.

The Privacy Policy covers what each of these can see and for how long they retain it.

Incident response

If we discover an incident that materially affects a user's account or data, we investigate first, remediate the vulnerability, and then notify the affected users. We aim to notify within 72 hours of confirmation, sooner when practical, along with a plain-language description of what happened, what data was implicated, and what we are doing about it.

Post-incident write-ups go in our internal runbooks. If an incident is significant enough to warrant a public summary, we will post it on this page and link it from the footer.

Reporting a vulnerability

If you believe you have found a security issue in Atlas, please email [email protected] with details and, if possible, a proof of concept. We ask that you:

• Give us a reasonable window to fix the issue before publishing details (typically 90 days).
• Avoid accessing, modifying, or destroying data belonging to other users. If you accidentally do, please tell us.
• Avoid running automated scanners against the production site — they generate a lot of noise that makes real issues harder to spot.

We do not currently run a paid bug bounty program, but we acknowledge every legitimate report and credit reporters on request once a fix has shipped. Threats, blackmail, or attempts to extract payment for withheld reports will be forwarded to law enforcement.

What we do not (yet) have

In the interest of honesty, here is what a larger platform might claim on a page like this — and what we do not have today:

• SOC 2 / ISO 27001. We do not hold a compliance attestation. Our subprocessors do; we do not.
• Formal penetration test. We have not commissioned one yet. When we do, we will note it here.
• Public status page. We monitor uptime internally. A public status page is on the roadmap; today, if the site is down, we tell users on our support email and via any push notifications the affected users have opted into.
• Bug bounty. No cash rewards yet — see the reporting section above.

We will update this section as those change. Nothing above is deliberately hidden — if you have a question about our posture that this page does not answer, please ask.