Security

The short version

A client’s upload is reachable only by whoever holds the exact link you sent them — guessing at random is rate limited into uselessness. Once it lands, row-level security in the database means your dashboard can only ever return your requests, even if a bug in Manilla’s own code forgot to ask for that. Manilla never sees a card number, a UPI ID, or a bank login — those go straight to Razorpay. The rest of this page is the detail behind those four sentences.

Client uploads

Files a client sends live in private storage, not a public bucket — there is no URL that lists or browses what has been submitted. Reaching a specific file requires the request’s access token, the same long random value in the link you send. A client page loaded without a valid token doesn’t 404 quietly forever, either: repeated wrong guesses from one address are rate limited, so the token space can’t be searched.

Uploading goes through a short-lived, single-use signed URL rather than a direct write to the bucket, and the file size that actually lands is re-checked against your plan’s ceiling server-side — the number the browser reports on the way up is never trusted on its own.

Database access

Every table that holds account data — requests, request fields, submissions, templates, profiles — has row-level security turned on in Postgres, with a policy that scopes access to the signed-in owner (directly, or through the request or template it belongs to). This is enforced by the database itself, underneath the application code, so a mistake in a page’s query can’t return another practice’s clients — the database refuses the row before it ever reaches Manilla’s server.

Operations that must cross that boundary — the reminder email sweep, resolving a client’s access token before they’re anyone’s account — run through a separate, internal service role, not the key your browser or your session ever holds.

In transit and at rest

Every connection to Manilla — the app, the API, every client link — is HTTPS only, with HTTP Strict Transport Security turned on so a browser that has visited once won’t downgrade to plain HTTP later. Data at rest — the database and file storage — is encrypted by Supabase’s infrastructure, which Manilla is built on rather than something Manilla implements itself.

Application-layer defenses

Every response from Manilla carries:

• X-Frame-Options: DENY — nothing on the site can be loaded inside someone else’s page, which closes off clickjacking a client’s upload screen.
• X-Content-Type-Options: nosniff — a browser can’t reinterpret an uploaded file as something it isn’t.
• Referrer-Policy: strict-origin-when-cross-origin — a client link contains its access token in the URL path, so a full referrer would hand that token to any third-party site a client page happens to link out to. This keeps the path internal.
• Permissions-Policy with camera, microphone, geolocation, USB and payment all turned off — Manilla only ever asks for a file from your device’s picker, never for hardware access.
• A Content Security Policy, currently running in report-only mode while we watch it against real traffic before it starts blocking anything. It is not yet enforced, and this page says so rather than implying otherwise.

The public, unauthenticated surfaces — a client filling in a request, minting an upload, confirming one — are rate limited per link and per address. We don’t publish the exact thresholds, for the same reason a lock doesn’t publish its pin length.

Payments

Card numbers, UPI IDs and bank details never reach Manilla’s servers — Razorpay (for INR) and PayPal (for existing USD accounts) collect and hold them directly. Every webhook Manilla receives from Razorpay is verified with an HMAC-SHA256 signature check before it’s trusted, using a timing-safe comparison rather than a plain string match, so the verification step itself can’t be timed and guessed.

Where data lives

Manilla runs on Vercel, with the app and API served from Mumbai. The database, file storage and authentication run on Supabase’s infrastructure, hosted in the United States (Oregon). We don’t currently offer India-only data residency — if that’s a hard requirement for your practice, ask us before you sign up, rather than after.

Deleting your account

Deleting your account from Dashboard → Settings removes your profile, every request and every template, and cascades through the database automatically rather than relying on a script to remember every table. You can additionally choose to delete every file your clients submitted at the same time, or leave that step for later.

What this isn’t

Manilla is built and operated by one person, the same as the rest of the product — see About. There is no SOC 2 or ISO 27001 certification, no 24/7 security team, and no formal incident-response SLA to point to, because none of those exist yet at this stage. What we can commit to: if something goes wrong with your data, we will tell you plainly and as soon as we know, not after a lawyer has cleared the wording.

Found a problem?

If you find a security issue, email hello@usemanilla.in with what you found and how to reproduce it. We’ll respond quickly, fix it, and tell you once it’s done — there’s no bug bounty program to offer alongside that, just a straight thank you.

Related

See the Privacy Policy for what we collect and why, and the Terms of Service for everything else.