This page is the vulnerability disclosure policy for Life Event App and the destination of the Policy field in /.well-known/security.txt. It also states how the service stores and protects data, for anyone reviewing us before they buy.

1. Reporting a vulnerability

Email contact@lifeeventapp.com with Security: at the start of the subject line, so it is routed ahead of general mail. Please include:

The URL, endpoint or app screen affected.
What you did, in enough detail that we can reproduce it.
What you were able to see, change or reach as a result.
Any script or request you used, and the date and time you ran it.

We aim to:

Acknowledge your report within 3 business days.
Tell you within 10 business days whether we have reproduced it and how we have rated it.
Keep you updated until the report is closed, and tell you when a fix ships.

These are targets, not a contractual commitment. If you have not heard from us inside those windows, send a follow-up to the same address.

2. Reporting abuse of an event page

Event pages are created by hosts, not by us. To report content on one, email contact@lifeeventapp.com with Abuse: at the start of the subject line and include the event link. We remove events used for phishing, impersonation or fraudulent fundraising. Guest photographs already wait for host approval before anyone else can see them, on every event.

3. Scope

In scope:

lifeeventapp.com and everything served under it.
send.lifeeventapp.com, the domain platform email is sent from.
The Life Event mobile client, once it is published to an app store.

Out of scope:

Services we use but do not operate. Report those to the vendor: Supabase, Stripe, Resend, Anthropic, Mux, Sentry, and Vercel, which hosts the site.
Denial of service, load testing, and anything that degrades the service for other people.
Social engineering of our people, our hosts or their guests, and physical attacks.
Automated scanner output with no demonstrated impact, and best-practice reports with no exploit path.
Findings that require a browser or operating system the vendor no longer supports.

4. Rules for testing

Test against your own account and your own events. You can create both for free.
Do not access, change, keep or share anyone else's data. If you reach data that is not yours, stop, and tell us what you reached rather than how much of it you could have taken.
Stop at proof. One record is enough to demonstrate access.
Do not run automated scans that generate real invitations, emails or payments.
Give us a reasonable chance to fix the issue before you publish it. We will agree a date with you rather than ask you to wait indefinitely.

If you follow these rules, we will treat your work as authorised research. We will not pursue legal action against you for it and will not ask a third party to. We cannot waive the rights of the vendors listed as out of scope above, so do not test them through us.

We do not run a bug bounty and do not offer payment. If you would like to be credited on this page when a fix ships, say so in your report.

5. How the service is built

In transit

The site is served over HTTPS only. Plain HTTP is redirected, and the site sends HSTS with a two-year lifetime covering subdomains. Every response also carries a content security policy, a frame policy, a referrer policy, a permissions policy that denies the device APIs the product does not use, and MIME-sniffing protection.

At rest

Application data is held in PostgreSQL on Supabase, encrypted in transit and at rest. Row-level security is enabled on every table holding account, event or guest content; the single documented exception is an internal log of which scheduled reminders have already been sent. Photo uploads are scoped to the event they belong to. Backups are retained for 30 days. Access to production data is restricted to a small set of authorised engineers.

Payments

Payments, donations and ticket sales run through Stripe. Card details are entered on Stripe's own pages and never reach our servers. We keep receipts and payment metadata.

Email

Platform email is sent through Resend from send.lifeeventapp.com, a separate subdomain from the one the website runs on, so bulk sending does not sit on the sending reputation of the domain the site is served from. SPF, DKIM and DMARC are published for it. An address that hard bounces or reports a message as spam is added to a suppression list and is not mailed again.

Where data is held, and for how long

Our infrastructure runs in the United States. Account and event data is kept while the account is active; after deletion it is removed within 30 days, some operational logs are kept up to 90 days for fraud prevention, and donation receipts are kept for 7 years for tax compliance. The full terms are in the privacy policy, which names our processors in section 5.

6. What we do not have

Listed rather than omitted, so the absence is on the record instead of being assumed either way.

No published security certification. Nothing on this page should be read as a SOC 2 report or an ISO 27001 certificate, and we claim neither.
No published penetration test.
No bug bounty programme.
No published PGP key, which is why security.txt carries no Encryption field.
No uptime target or service level commitment.

7. Contact

Security and abuse: contact@lifeeventapp.com. The machine-readable version of this contact is at /.well-known/security.txt.