/Docs

How Hackley Clubz is Secure

Hackley Clubz was designed with security in mind from the start. This page describes the practices we follow to keep the application and its users’ data safe.

No passwords — Google Sign-In only

Hackley Clubz has no passwords. Users sign in with their existing Google account, so there is no password database to steal, no password reuse risk, and account security (including two-factor authentication) is handled by Google and the school’s Workspace policies.

Sign-in tokens from Google are verified on the server — the cryptographic signature, issuer, and audience of every Google ID token are checked against Google’s published signing keys before a user is logged in. We never just trust what the browser or app sends us.

Only Hackley accounts can log in

Login is restricted to Hackley School Google Workspace domains (students and faculty). This restriction is enforced on the server for both the website and the mobile apps, so it cannot be bypassed by a modified client. Anyone with a non-Hackley Google account is turned away and offered the demo app instead.

The demo app is the mirror of this rule: it contains no real student data, and real Hackley accounts are blocked from it so students can’t accidentally use it.

Every page requires login

Every page in the application requires an authenticated session — the only exceptions are the login and logout pages themselves (and public legal documents like the privacy policy). The mobile apps authenticate every API request the same way.

Beyond simply being logged in, the login check also enforces account state: suspended accounts are signed out immediately, and deleted accounts cannot access the app.

An API that enforces application logic

The mobile apps talk to the server through an API that enforces all application rules — permissions, membership, and moderation — on the server side. Clients never get to decide what they are allowed to do; the server checks every request.

API sessions use 256-bit random tokens. Only a cryptographic hash of each token is stored in our database, so even a database leak would not expose usable session tokens. Tokens expire after 30 days of inactivity and can be revoked.

We store only the data we need

We practice data minimization: the only personal information we store is a user’s first name, last name, email address, and profile photo. There is nothing else to lose.

As a rule, the application does not email users directly, so email addresses are never exported into third-party email tools or mailing lists.

When a user deletes their account, their personal data is removed after a short reclaim window.

Protection against common web attacks

  • SQL injection — all database queries use prepared statements with bound parameters, the industry-standard defense against SQL injection.
  • Cross-site request forgery (CSRF) — every form submission carries a cryptographically random CSRF token that is verified on the server using constant-time comparison.
  • Cross-site scripting (XSS) — user-generated content is escaped before it is rendered in HTML.

Server and source code hygiene

  • Apache directory listings are disabled, so the structure of the server can’t be browsed.
  • The source code repository on GitHub is private.
  • Google Sign-In verification is implemented with no third-party dependencies, keeping the supply-chain attack surface small.
  • Administrative actions are recorded in an activity log, so there is an audit trail of who did what.

Security (protecting the system and data) goes hand in hand with safety (protecting the people using it). For content reporting, moderation, and suspension flows, see Safety in Hackley Clubz.