What is in place, what is not yet, and how to report a problem.

The short version

• Every page is sent over an encrypted connection.
• Card numbers go from the buyer's browser to Stripe. SeedStand's servers never see them.
• Each district's sales, orders, customers and payments are kept apart by the database.
• Volunteers' check-in links cannot record payments or show customers' email addresses.
• Not in place yet: two-step sign-in for district staff, an independent security test, and a SOC 2 report.

Reporting a vulnerability

security@seedstand.org. Reports go straight to the security mailbox.

Please do not access, change, or copy 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 an encrypted connection (TLS), and browsers are told to insist on it for two years (HSTS).
• The admin and the volunteer check-in screen cannot be shown inside another site's frame. The public online store deliberately can be, so a district may embed its own sale page in its own website; the online store carries no sign-in and no authority.
• Each district's sales, orders, customers and payments are separated at the database by row-level security; a query on them runs inside one district's scope or not at all.
• Links that grant access are signed, and each works for one purpose only, so one kind of link cannot be used as another. A tampered link is refused. Sign-in sessions and volunteer check-in links expire. Receipt and unsubscribe links do not, so an old email or printout still works.
• Card numbers never touch our servers. Payment details go from the buyer's browser to Stripe; we receive the result.
• Volunteer check-in links can check people in. They cannot record payments, mark orders not picked up, or see customers' email addresses, and a forged request to do so is refused.
• Repeated failed sign-in attempts are throttled. Sign-up and pay-later checkout are guarded against automated abuse, including a limit on how many unpaid orders one email address or one connection can hold.
• A district account can end every signed-in session at once with Sign out everywhere, and changing the password does the same. Failed sign-in attempts made elsewhere do not lock out a browser that has signed in to that account before.
• Text typed by a buyer is stored as text and shown as text. A script tag in a customer name shows as the characters, not as a script.
• Secrets live in the hosting platform's encrypted variables, not in the source code. Replies to order emails go to the district's contact email once the district has set one; until then they reach SeedStand.
• A Content-Security-Policy is enforced on every page. It names the outside services a page may run code from or frame, such as Stripe for card payments, and the browser refuses any other script or frame. Images are the one exception: a district may use a logo hosted anywhere, so images are allowed from any secure (https) address. Blocked attempts are logged.
• Dependencies are watched automatically. A security advisory in a package we use raises an alert, routine updates are proposed every week, and a check runs every Monday against the packages we ship. A person reviews every update before it is applied; nothing updates itself.

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.
• District accounts sign in with a password. Two-factor sign-in for district users is not yet offered.
• The Content-Security-Policy still permits inline scripts and inline styles, because the web framework the site is built on writes both into every page.
• A receipt link cannot be turned off for one order; anyone who holds it can open that order's receipt.
• The Monday check fails only on high or critical advisories in the packages we ship; lower-severity and development-only advisories are read by a person instead. A few advisories that affect only the tools that build the site, not the running site, are accepted for now, each with a written reason and a review date.

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. Anthropic (Claude), for the optional catalog import from an order form, receives only the file you upload, and only when you use that import. The privacy page lists these processors and what each receives. Privacy · Status

We revise this page when we change how the software is secured. The date it was last revised is at the bottom. Last revised: October 7, 2026.