K
Kunjara OS
← Back to app

Legal · Security

API Security Guidelines

Effective: 6 May 2026 · Version 1.0

These guidelines define the security standards that govern how Kunjara Technologies builds, operates, and protects the Kunjara OS API and related infrastructure. They also establish rules for authorised developers and partners integrating with our platform, and describe our responsible disclosure process for security researchers.

1. Authentication and authorisation

All access to the Kunjara OS API requires authentication:

  • User sessions are managed via Supabase JWT tokens with a 1-hour expiry and automatic refresh.
  • API routes validate session tokens on every request server-side — no client-side trust.
  • Row-Level Security (RLS) is enforced at the database layer; users can only access their own data regardless of API-layer bugs.
  • Service-role keys (Supabase admin) are never exposed to the client and never committed to version control.
  • All privileged operations require a valid authenticated session scoped to the owning user_id.
  • Failed authentication attempts are rate-limited per IP and per email address.

2. Secret and key management

  • All secrets (OpenAI API keys, Razorpay keys, Supabase service role, Upstash tokens) are stored exclusively as server-side environment variables.
  • Secrets are never logged, returned in API responses, or interpolated into client-side bundles.
  • Environment variables are injected by Vercel at build/runtime — never stored in .env files committed to the repository.
  • Secret rotation is performed immediately upon any suspected exposure. Rotation does not require a code deployment.
  • Webhooks are verified using HMAC-SHA256 signatures before processing. Raw request bodies are preserved for signature validation.
  • Any developer or contractor with access to production secrets must acknowledge the NDA & IP Agreement.

3. Input validation

All API endpoints validate incoming request bodies using Zod schemas before executing any business logic. Validation rules include:

  • String fields: trimmed, maximum length enforced, type coercion disabled.
  • Numeric fields: parsed and range-checked — no raw user-supplied values are passed to third-party APIs.
  • Enum fields: validated against an exhaustive allowlist.
  • File uploads: type and size validated server-side; MIME type sniffing is not relied upon.
  • SQL injection: not possible — all database access uses Supabase's typed query builder with parameterised queries.
  • XSS: React escapes all JSX output by default; dangerouslySetInnerHTML is prohibited without a security review.

4. Rate limiting

Rate limiting is enforced on all public-facing and authenticated API routes using Upstash Redis with a sliding window algorithm:

  • AI generation endpoints: 10 requests per user per minute.
  • Authentication endpoints (login, signup, reset): 5 requests per IP per 15 minutes.
  • General API endpoints: 60 requests per user per minute.
  • Public endpoints (room share link, public proposal view): 30 requests per IP per minute.
  • Webhook endpoints: verified by signature before rate limit check — signature failures return 401 without rate limit consumption.
  • Accounts exceeding limits repeatedly are flagged for manual review.

5. Data in transit and at rest

  • All traffic is encrypted in transit using TLS 1.2+ enforced by Vercel's edge network.
  • HTTPS is mandatory — HTTP requests are redirected to HTTPS at the edge.
  • Data at rest is encrypted by Supabase (AES-256) at the storage layer.
  • AI-generated images returned as base64 data URIs are stored in Supabase JSONB columns — not in public blob storage — to prevent unauthorised URL access.
  • Payment data (card numbers, UPI handles) is never stored by us; it is tokenised by Razorpay.
  • Personally identifiable information (email, name) is stored only in the Supabase auth schema with access restricted to service-role operations.

6. Third-party dependency security

  • Dependencies are pinned to specific minor versions in package.json to prevent unexpected breaking changes.
  • Dependabot (or equivalent) alerts are reviewed weekly.
  • Third-party AI providers (OpenAI) receive only the minimum data necessary to fulfil the generation request — no user PII is sent unless explicitly part of the prompt submitted by the user.
  • Razorpay webhook payloads are verified using the Razorpay SDK's built-in signature validation before any order state is updated.
  • Supabase is hosted in a region compliant with applicable data localisation requirements.

7. Logging and monitoring

  • Server-side API errors are logged with request metadata (route, method, status code, timestamp) but without request bodies that may contain sensitive data.
  • Logs do not contain API keys, passwords, card numbers, or user PII beyond anonymised identifiers.
  • Unusual patterns (spike in 4xx/5xx errors, abnormal credit consumption) trigger alerts for manual review.
  • Vercel runtime logs are retained for 30 days and access is restricted to authorised engineers.

8. Prohibited API usage

The following are strictly prohibited and will result in immediate account termination:

  • Automated scripted access to AI generation endpoints at a rate exceeding published rate limits.
  • Attempting to extract, scrape, or systematically collect AI model outputs for training competing models.
  • Probing, fuzzing, or attempting to exploit API endpoints without written authorisation from the Company.
  • Attempting to access data belonging to other users by manipulating request parameters (IDOR attacks).
  • Using the API to relay requests to third-party services in a way that bypasses our content moderation.
  • Reselling API access or API-generated outputs as a white-label service without a signed commercial agreement.

9. Responsible disclosure

We take security seriously and welcome reports from security researchers. If you discover a vulnerability in the Kunjara OS platform, please disclose it responsibly:

  • Email a detailed description of the vulnerability to security@kunjaraos.com with subject line "Security Disclosure".
  • Include the affected endpoint or component, steps to reproduce, potential impact, and any proof-of-concept (non-destructive).
  • Do not access, modify, or delete any data belonging to other users in the course of your research.
  • Do not disclose the vulnerability publicly until we have acknowledged receipt and had a reasonable time (typically 30 days) to patch it.
  • We will acknowledge receipt within 3 business days and provide a remediation timeline.
  • We do not currently operate a paid bug bounty programme, but we will publicly credit researchers who report valid issues (with their consent).

Report vulnerabilities to: security@kunjaraos.com

10. Contact

Security disclosures: security@kunjaraos.com
General legal queries: legal@kunjaraos.com