Security

The most important guarantee in Chapter is that one club can never read another club's data. That is enforced by row-level security policies in the database itself — every single query is filtered by “is this person an active member of this club?” before any row is returned.

This matters because it holds even if the app has a bug. Hiding a button in the interface is not security; refusing to return the row is. Every table in Chapter has these policies enabled, with no exceptions.

A member cannot approve their own volunteer hours — the database rejects it, not just the button. Officers cannot modify advisors. Check-in codes are validated on the server against an open event within a time window, so a shared code cannot be replayed later. One person can hold different roles in different clubs, and each is evaluated independently.

• Proof photos live in a private store, reachable only through short-lived signed links, and only by the member who uploaded the photo and their officers.
• Anonymous suggestions are saved with no author recorded, so anonymity is a property of the data rather than a promise in the interface.
• Meeting notes and the transition vault are restricted to officers and advisors.
• Passwords are never stored by Chapter at all; sign-in is handled by Supabase Auth.

• All traffic is served over HTTPS, with HSTS instructing browsers never to fall back to an unencrypted connection.
• A Content-Security-Policy plus anti-framing and MIME-sniffing headers are sent on every response, limiting script injection and clickjacking.
• Requests are rate limited per source, so a single client cannot flood the app or grind away at sign-in.
• Every automated endpoint authenticates its caller: payment webhooks are cryptographically signature-verified, scheduled jobs require a secret, and one-click email unsubscribe links are signed so only links Chapter issued will work.
• Administrative database credentials exist only on the server and are never included in anything sent to a browser.

Two things look alarming to an automated scanner but are working as designed, and we would rather explain them than have you wonder.

The app's JavaScript is readable. That is true of every website — a browser cannot run code it cannot read. No secrets live there; anything sensitive runs on the server.

The public API key is public.Chapter's browser code carries an identifying key for the database service, exactly as designed by that service. It grants no access on its own — the row-level security policies described above decide what any request may actually read, based on who is signed in.

If you believe you have found a security issue, email adminchaptersupport@gmail.com with what you found and how to reproduce it. Reports are welcome and are read by a human, usually the same day.

Please keep testing to your own club's data, and do not run denial-of-service or flooding tests, attempt to reach another club's records, or use automated scanners against the live site — those affect real students mid-meeting. Ask first and we will happily set you up somewhere safe to test.

Chapter is built and maintained by a student, not a security team, and it is young software. What that means concretely: the protections above are real and verified, but Chapter has not had a third-party audit or penetration test, and does not hold SOC 2 or similar certification. If your district requires that, say so and we will tell you plainly where we stand rather than guess.

Details on what data exists in the first place are on the privacy page.