Security & Privacy

What this covers

SeaDays is a cruise planning and community app (iOS, Android, and web) operated with a marketing site at seadays.app. Account authentication is provided by Supabase Auth. Application APIs run on Supabase Edge Functions. Some trip and social data is stored in Postgres with Row Level Security; other features use a server-side key-value store that is not readable by the public anon key.

Accounts and sessions

• Sign-in uses Supabase Auth with PKCE (Proof Key for Code Exchange) for OAuth.
• The mobile/web client is configured with the project’s public anon (publishable) API key only. The service-role key is not shipped in the app.
• Protected API routes require a valid user session. Public read endpoints are limited to feeds and similar catalog content.
• Waitlist email export requires a CMS administrator session, not the public anon key.

Private data between users

Private APIs require a valid signed-in session. Message threads, diagnostic dumps, points balances, and buddy lists are bound to the authenticated caller. Another signed-in user cannot read or wipe your private conversation or account dump by substituting a user id in the URL.

Some profile-style fields (public cruise stats and achievements) remain readable so you can view another sailor’s public profile. That is product behavior, not a private-data leak.

Database access

• Row Level Security is enabled on SeaDays application tables in the audited Postgres project.
• The key-value table used by the Edge Function is not granted to anon or authenticated client roles.
• Voyage costs, drink logs, and similar user tables are scoped to the signed-in user in RLS policies.
• Internal tables such as blog drafts, moderation reports, and carbon-funding ledgers are not readable through the client API after the 17 August 2026 grant hardening.

Files and media

• Chat images, note images, and profile pictures are stored in private buckets. Client access is limited to the owner’s folder, or to time-limited signed URLs issued by the server after authentication.
• Public buckets are used for marketing and Portside article media (SeadaysPublic, portside images, and the auth-redirect asset bucket).

Website (seadays.app)

• The marketing site is served over HTTPS (HTTP/2 observed on 17 August 2026).
• The site uses Google Analytics 4 with Consent Mode v2 defaults that deny analytics and ads storage until consent is updated.
• The contact form posts to the SeaDays API. Guest submissions are rate-limited and are not stored under another user’s account id.

GitHub Pages, which hosts seadays.app, does not send Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, or similar HTTP response headers. A Content-Security-Policy meta tag may be present on some pages; it is not a substitute for HSTS or frame-ancestors. We do not claim those HTTP headers are in place until a CDN or reverse proxy is configured in front of GitHub Pages.

Testing and maintenance

• SeaDays runs automated unit tests for authentication matching, HTML sanitization, and Edge ownership checks as part of development.
• A technical security audit of the app, database policies, Edge Functions, and seadays.app was completed on 17 August 2026. Findings and remaining risks are tracked internally.

We do not claim a third-party penetration-test certificate or a public bug-bounty program.

Privacy and GDPR

We publish a Privacy Policy, a Cookie Policy, and a GDPR information page. Those documents describe how we handle personal data and how you can contact us. This is not a GDPR certification, ISO certification, or SOC 2 report.

What we do not claim

We have not published evidence for, and therefore do not claim: SOC 2, ISO 27001, HIPAA, GDPR certification, encryption-at-rest configuration, a bug-bounty program, or a promise that data is never used to train AI models.

Related policies

• Privacy Policy
• Terms of Use
• Cookie Policy
• GDPR

Contact

Security and privacy questions: