What is true, what is not yet, and how to tell us.

Reporting a vulnerability

security@seedstand.org. Reports are read by the people who write the software, not by a ticket system. You will hear back from a person.

We will not pursue legal action against anyone who reports a genuine vulnerability in good faith and gives us reasonable time to fix it.

Please do not access, modify, or exfiltrate other people's data while testing; a proof of concept against your own district account is enough.

The same contact is published in the standard place, /.well-known/security.txt.

What is true today

• Every page is served over TLS, and browsers are told to keep it that way for two years (HSTS).
• The admin and the volunteer check-in screen cannot be shown inside another site's frame.
• Each district's data is separated at the database by row-level security; a query runs inside one district's scope or not at all.
• Links that carry authority — sign-in sessions, volunteer check-in links, receipt links, unsubscribe links, and the form-timing tokens — are signed, expire, and are bound to one purpose, so one kind of link cannot be replayed as another. A tampered link is refused.
• Card numbers never touch our servers. Payment details go from the buyer's browser to Stripe; we receive the result.
• Volunteers can check people in and nothing else: they cannot record payments, mark orders not picked up, or see customers' email addresses. A forged request to do so is refused.
• Sign-in attempts are throttled. Sign-up and pay-later checkout carry an abuse guard: a hidden field bots fill, a timing check, and caps on how many unpaid orders one email or one connection can hold.
• Text typed by a buyer is stored as text and shown as text — a script tag in a customer name renders as the characters, not as a script.
• Secrets live in the hosting platform's encrypted variables, not in the repository. Replies to order emails go to the district, not to us.

What is not yet true

• No independent penetration test has been performed yet. One is planned once the first districts are paying customers, and its letter will be linked here.
• There is no SOC 2 or ISO 27001 report. We are a small company; we would rather say so than imply one.
• District accounts sign in with a password. Two-factor sign-in for district users is not yet offered.
• The Content-Security-Policy is limited to frame protection today; a full policy is being introduced in report-only mode first.
• Automated dependency scanning is not yet wired into the build.

Where the data is

The application runs on Vercel and the database is Neon Postgres, both in the United States. Transactional email goes through Resend; card payments, where a district turns them on, go directly to Stripe and card numbers never reach our servers. The privacy page lists these processors and what each receives. Privacy · Status

This page changes when the facts change, in the same commit as the code. The date it was last revised is at the bottom. Last revised: September 5, 2026.