Security

7.1 Authorisation is in the database

Every table has row-level security, and access to an event is resolved from your session against your seat on that event. The application layer checks too, but the database is the thing that says no. A vendor invited to one wedding cannot read another wedding's data by calling the API directly — this is asserted by an automated test that runs on every change.

7.2 Documents

Uploaded files live in a private bucket. There is no public URL for a contract or a floor plan. Every read is a short-lived signed link issued per request, checked against your own access to that event, and expiring in minutes.

Uploads are limited by type and size, enforced by the storage layer before a byte is written, not just by the form.

7.3 Sign-in

Emailed sign-in links and Google. No passwords, so no password to reuse, leak or guess. Links are single-use and short-lived.

7.4 Invitations

An invitation token is a long random value, tied to one event, expiring after 30 days, and revocable at any time by the event's owner. Revoking ends access immediately.

7.5 What we have not done

Stated plainly, because a security page that only lists strengths is marketing:

• Uploaded files are not scanned for malware.
• We hold no third-party security certification — no SOC 2, no ISO 27001, no penetration test report. Runsheet is a young product built by a small team.
• We do not offer single sign-on, audit-log export or IP allow-listing.

7.6 Reporting a vulnerability

Email support@runsheetforyou.com with "Security" in the subject. Tell us what you found and how to reproduce it. We will acknowledge within 2 business days.

Please do not run automated scanners against the production site, access data belonging to anybody but yourself, or degrade the service for other people. We will not pursue anybody who reports a genuine issue in good faith and gives us a reasonable chance to fix it before saying anything publicly. We do not currently pay bounties.