Security

• Browser access is restricted by an explicit list of allowed origins. There is no wildcard: the code refuses to accept "*" even if someone sets it in configuration, because an API that accepts credentialed requests from any origin has no origin policy at all.
• The first-party origins are hard-coded in the source rather than read from configuration, so a mistyped environment variable cannot silently widen access.
• Outside production a localhost pattern is allowed for development. In production that pattern is switched off.

• Sign-in is Google, through Supabase. The app sends the resulting access token to our API.
• Our server verifies the token signature itself. It does not accept a token because it looks well-formed: it checks the signature against the shared secret, or against Supabase's published signing keys, and rejects anything that fails.
• Where a Google identity token is verified directly, our server checks the signature with Google and also checks that the token was issued for our application and by Google — without that audience check, a token minted for a different app would be accepted.
• We also issue our own opaque session tokens, stored server-side. Because they are stored, they can be revoked instantly — which is what makes "delete my data" able to end every session on every device at once.
• Local, password-free sign-in exists for development and offline clinic use, and the code disables it automatically as soon as real authentication is configured, so a production deployment cannot be entered through that door.

• Row-level security is enabled on every application table — learners, staff, sessions, attempts, reviews, consent events, plans, subscriptions, payments, entitlements, analytics and devices.
• No policy grants access to the public anonymous or authenticated keys. The practical effect is that the keys shipped inside the app cannot read a single row of application data.
• Our API server reaches the database with a service-role credential that exists only as a server secret.
• Voice recordings live in a private storage bucket. It is not publicly readable. The app never writes to it and never reads from it directly; only the server, holding the service-role key, can.
• Responses that carry a recording, an account detail, a billing record or an admin view are marked no-store, so no proxy or CDN keeps a copy.

• Every secret is set on the server platform as a secret. None is committed to the repository and none appears in the deployment configuration file.
• The service-role database key, the Razorpay secret, the Razorpay webhook secret and the Google Play service account are held only on the server. None of them is present in the Flutter app, on Android or on the web.
• The Flutter app carries only the public identifiers it must — the Supabase URL and the public anonymous key, and the Razorpay public key id. None of those can read data or move money on their own.
• Payment amounts are always taken from our own plan catalogue on the server. A price sent by a client is ignored, because a price the client chooses is a price the client sets.

• The analysis endpoint is rate limited with a sliding window: 30 requests per minute and 600 per hour for a signed-in learner, and a third of that for requests with no account, keyed by IP address.
• A sliding window rather than fixed buckets, so a burst cannot be smuggled across a minute boundary.
• Refused requests are not counted against you. A client that ignores a rate-limit response cannot lock itself out permanently.
• An upload larger than 8 MB is refused — first on the declared length, then again while the body is read, so a lying length header changes nothing.
• Every consequential action taken by a staff member or an administrator is written to an audit log with who, what, when, and the before and after values.

• An upload must decode as valid audio. Anything that does not is rejected with a clear error rather than passed further in.
• A clip shorter than 50 milliseconds after silence trimming is rejected as empty.
• Audio beyond 30 seconds is not analysed, which bounds both the cost and the memory of a single request.
• The kind of practice being performed — and therefore what it costs — is decided on the server from the target text, never from a field the client sends.
• Every stored recording is hashed on write, so a file can be checked against the record of what was stored.

Every API response carries: strict transport security; a no-sniff content type so a JSON error body can never be executed as HTML; frame denial; a referrer policy that does not leak full paths to third parties; a permissions policy that switches off camera, geolocation, payment and USB; and a cross-origin resource policy limiting who may embed a response.

• One structured line per request: a request id, method, path, status, how long it took, and the numeric user id when there is one.
• Request bodies, audio and email addresses are deliberately never logged.
• The request id is returned to the client, so a learner reporting a problem can quote a number that finds the exact line.
• A health endpoint reports whether the machine can actually see the model registry, so a server that started but cannot serve fails its check instead of quietly accepting traffic.
• Fly health checks and deploy logs; operators (founders/admins) watch for failed health and billing alerts. We do not currently publish a public status page.

• The main API and storage sit in Asia. Voice scoring may process prepared audio outside India.
• This website and the web app are hosted on a global edge network.
• Lesson media may be delivered via a content network when published.
• Exact vendor names are listed under Privacy → Vendor names (optional detail).

Database and storage backups follow our hosting plan. Deleted personal data can remain in encrypted provider backups until those backups are overwritten (typically up to about 30 days).