Transport security
The production application is served over HTTPS and sends browser security headers, including HTTP Strict Transport Security.
Data minimization
Zoom identifiers used for session coordination are hashed where practical. BrainSync avoids broad Zoom REST scopes.
Account protection
Creator passwords are stored only as salted, one-way hashes. Authentication uses secure, HTTP-only cookies in production.
Signed integrations
Zoom context and webhook requests are verified before trusted lifecycle actions are accepted.
Media isolation
Uploads use restricted object-storage write access and controlled public delivery for media intended to appear in activities.
Managed infrastructure
Application data and media rely on managed MongoDB Atlas and AWS services with access restricted to the application environment.
Application and account security
- Passwords are salted and hashed; BrainSync does not store the original password.
- Production authentication cookies are HTTP-only, secure, and use same-site protections.
- Creator-only routes and resources validate ownership on the server.
- Secrets such as database credentials, Zoom client secrets, webhook tokens, and AWS credentials belong in the server environment—not browser code or source control.
- Uploaded files are validated by media type and size before acceptance.
Zoom App security
BrainSync treats browser parameters as untrusted. The in-client experience exchanges Zoom's signed app context with the BrainSync server before using meeting or user context. Webhook endpoint validation and event messages are authenticated using Zoom's signing mechanism and a private secret token.
The current experience requests only the capabilities needed to determine app context and manage a Play Together collaboration. It does not require meeting audio, video, chat, recording, contact, calendar, or account-administration access.
Live session protection
- Each live activity receives an unpredictable internal identifier and a temporary join PIN.
- Hosts control lobby locking, session progression, and ending the activity.
- Participant resume tokens and external identity references are treated as credentials and are not shown in public reports.
- Server-side checks determine whether a player can join, answer, resume, or control a session.
- Creators should end abandoned sessions and avoid posting PINs publicly unless an open event is intended.
Infrastructure and media
BrainSync is hosted on AWS, with application records stored in MongoDB Atlas and media stored in Amazon S3. Public activity images may be delivered through Amazon CloudFront. The upload path remains authenticated even when the final activity image is intentionally public.
Access to production infrastructure is limited to administrative needs. Logs may record operational metadata needed to diagnose reliability and security problems, but secrets and passwords should never be deliberately logged.
Security limitations
No online service can guarantee absolute security or uninterrupted availability. BrainSync uses safeguards appropriate to its current scale and continues to improve them as the platform grows. Creators should not use BrainSync to collect highly sensitive information such as payment-card data, government identifiers, medical records, passwords, or private access tokens.
Report a vulnerability
Responsible disclosure
Email support@jrpadhi.com with the affected URL, reproducible steps, impact, and supporting evidence. Do not access other people's data, disrupt live sessions, run denial-of-service tests, or publish the issue before we can investigate.
We aim to acknowledge credible security reports within two business days. This contact process is not a promise of payment or a public bug-bounty program.
Privacy and deletion
Security practices work alongside the Privacy Policy. Account owners and participants can use the verified deletion process to request removal of applicable personal information.
Include the relevant game PIN or approximate time of the issue, but never send a password.