Security at Ano

Every table in our database has Row Level Security (RLS)enabled. Access rules are enforced by the database itself, not just by application code: a creator can only read and modify their own events, a vendor can only manage their own listings and proposals, and a guest can only see invitations addressed to them. Even if a bug slipped past our application layer, the database would still refuse to return another user's data.

These policies are covered by an automated RLS test suite that runs in continuous integration whenever the database schema changes, so access rules cannot be weakened silently.

Authentication is handled by Supabase Auth. Passwords are stored only as salted hashes — never in plaintext. Sessions use short-lived JSON Web Tokens (JWTs) delivered via cookies.

Every request to the platform passes through an edge-level guard that verifies the session and reads the user's role (creator, vendor, or guest) directly from the signed JWT. Hard role boundaries are enforced before a page ever renders: vendors cannot reach creator routes, guests cannot reach vendor or creator routes, and admin routes are restricted to admins. Application layouts apply the same checks again as defence in depth.

All traffic to Ano is served over HTTPS. We send a Strict-Transport-Security header with a two-year max-age, includeSubDomains, and preload, so browsers refuse to connect insecurely. Data stored by our database provider is encrypted at rest.

Every response also carries a set of hardening headers:

• A Content Security Policy that restricts scripts, styles, images, and network connections to our own origin and our infrastructure providers, and blocks the site from being embedded in frames.
• X-Frame-Options: DENY — clickjacking protection.
• X-Content-Type-Options: nosniff — prevents MIME-type confusion.
• Referrer-Policy: strict-origin-when-cross-origin — limits what other sites learn about your browsing.
• Permissions-Policy — camera, microphone, and geolocation access are disabled entirely.

Security-relevant actions — publishing an event, inviting a guest, accepting an invitation — are recorded in an audit log. The log is append-only by design: users can only write entries attributed to themselves, and no user-facing role can read, edit, or delete entries. This gives us a tamper-resistant trail for investigating any incident.

Sign-in, sign-up, verification, and waitlist endpoints are rate-limited at the edge by client IP to blunt credential-stuffing and request floods. This sits in front of Supabase Auth's own server-side rate limits on OTP and sign-up endpoints, so authentication abuse is throttled at two independent layers. Our edge limiter is best-effort by design; the authoritative limits are enforced server-side by our auth provider.

Ano is designed around India's Digital Personal Data Protection Act, 2023:

• Recorded consent: the timestamp and version of your acceptance of our Terms and Privacy Policy are stored, as the Act requires.
• Cookie consent: a consent banner lets you decline non-essential cookies; only strictly necessary session cookies are set without consent.
• Right to erasure: account deletion requests are logged in a dedicated, RLS-protected table and fulfilled by anonymising your personal data, so shared event records involving other people are not destroyed in the process.

Full details are in our Privacy Policy.

• Dependency scanning: every push to our main branch runs an audit of third-party dependencies that fails the build on high-severity or critical vulnerabilities.
• Static analysis: GitHub CodeQL scans our TypeScript codebase on every push and pull request, plus a scheduled weekly run.
• RLS regression tests: database access policies are tested in CI against a local database instance before schema changes can merge.

When you share an invitation via a public link, the page exposes only a deliberately limited set of fields — event title, hosts, dates, and city-level location. Public links work only if you have explicitly enabled sharing for that event, and anonymous visitors have no direct database access of any kind.

If you believe you have found a security vulnerability in Ano, we want to hear from you. Please email security@ano.in with a description of the issue, steps to reproduce it, and any relevant details.

• We will acknowledge your report within 72 hours.
• We ask that you give us a reasonable window to fix the issue before public disclosure.
• Please do not access, modify, or delete other users' data while researching, and do not run automated scans against production.
• We will not pursue action against researchers who report in good faith within these guidelines.