How your account and data are protected

You sign in with Google, or with an email address and password, through Firebase Authentication. Passwords never reach our servers: Firebase stores a salted hash (scrypt), locks an account for a while after repeated wrong attempts, and the sign-in form answers the same way whether or not an address has an account. A new email account opens only after the address is verified by a link, and the server refuses an unverified sign-in too; reset links come from Firebase, work once and expire after an hour; changing the password or deleting the account asks for the current password (or a fresh Google sign-in) first. Every request to the server carries a short-lived signed token that the server verifies against Google's published keys, checking the issuer and the project it was issued for, before anything is read or written. There is no session cookie that could be stolen or forged; the one cookie the site sets is a flag that says you are signed in and carries no secret.

Super-admin access is limited to named accounts configured on the server and checked on every admin request.

Every record is read and written under the signed-in account that owns it. Coaching and chat records are reachable only by the two people in the relationship, and only for the categories the member turned on. Gym records are reachable only by the gym's owner and the co-managers the owner added. A member's own gym data reaches their account only after they confirm the gym.

Identifiers of other people are stripped from responses: a member never sees a coach's internal id, a coach never sees a client's, invoices carry names and not ids.

All traffic uses TLS; the site sends HSTS so browsers refuse plain HTTP. Data at rest is encrypted by the database and storage providers. Photos, voice notes and sign-up photos are stored as private objects and opened only through signed links that last minutes; uploads go straight from your browser to storage through a one-minute signed link that fixes the file type, size and name, and the server checks the file's first bytes after upload. Images are resized on your device before upload, which strips location data.

Requests are rate-limited per network address, with tighter limits on the public catalogue, sign-up forms and invitations. Each account also has daily caps on invitations, uploads, enquiries and announcements, so a compromised or abusive account cannot spam others. Request bodies are size-limited. Browser security headers (frame-ancestors none, nosniff, referrer policy, permissions policy, base-uri and form-action restrictions) are set on every response.

Server-to-server calls are allow-listed: push notifications go only to the browsers' push services, and the server fetches only files it stored itself.

Secrets, including the payment keys, live in the hosting provider's encrypted configuration, never in the code repository. Signing keys for share links and the rate limiter are dedicated random values. Dependencies are audited on every build. Hosting is on Vercel, the database on MongoDB Atlas with access restricted to a dedicated user, and files on DigitalOcean Spaces in Bangalore.

Backups of the database are kept for 7 days. Deleting your account removes your records from the live database at once and from backups when they roll over.

Card, UPI and bank details are entered on Razorpay's own checkout (or Google Play and the App Store in the apps) and never pass through or rest on our servers; Razorpay is PCI DSS certified and RBI-licensed. What we keep is the plan, its dates and the provider's payment reference. Razorpay tells our server about a payment through a webhook whose signature we verify against a shared secret before anything changes, and the amount must match the plan's price before the plan is granted, so a tampered checkout cannot buy a year for a month's money.

If we learn of a breach affecting personal data, we contain it, tell affected people without delay in plain words with what happened and what to do, and report it to the Data Protection Board of India within 72 hours as the DPDP Rules require. Questions about an incident go to hello@healthyhueman.example.

If you find a vulnerability, please tell us before telling anyone else: hello@healthyhueman.example with the subject "Security report". Give us a reasonable time to fix it, do not access other people's data beyond what is needed to show the issue, and do not run denial-of-service tests. We acknowledge within 24 hours, keep you updated, and credit you if you wish. We will not take legal action against good-faith research that follows these rules.