Security

Last reviewed: 2026-05-02 · Next scheduled review: 2026-11-02

The short version. TLS in transit, encryption at rest for sensitive fields, OAuth-only sign-in, network-isolated runtime sandboxes, audit logging, breach-notification within statutory deadlines, and a coordinated disclosure programme for security researchers.

1. Data in transit

  • All connections between the OffCoder mobile app, the website, and our backend are encrypted with TLS 1.2 or higher. We do not accept unencrypted HTTP for API endpoints.
  • Modern cipher suites only (no RC4, no 3DES, no SSLv3). Minimum TLS 1.2 enforced; we plan to require TLS 1.3 for all clients before public launch.
  • HSTS is enabled on the API and Website, with a meaningful max-age and includeSubDomains.

2. Data at rest

  • Database storage uses provider-side AES-256 disk encryption.
  • Application-level fields holding secrets — your BYOK API keys, project secrets injected as runtime env vars — are additionally encrypted with AES-256-GCM using keys held in a separate application secret manager.
  • Backups are encrypted and replicated across at least two regions for durability.

3. Authentication

  • OAuth-only sign-in for new accounts (Google, GitHub, GitLab, Bitbucket, LinkedIn). Email/password is intentionally disabled to remove the timing-side-channel and credential-stuffing surface. OffCoder does not maintain user passwords; there is no password to reset, no password-reset email, and no password-related attack surface on our side.
  • Refresh tokens are rotated on every refresh and bound to a per-device session, so re-use of an old refresh token signals theft and triggers session termination.
  • Optional biometric lock on the mobile app (Settings → Privacy → Require biometric on launch). Biometric matching happens entirely on your device via the platform credential APIs — Android BiometricPrompt today, and iOS LocalAuthentication if and when iOS support ships. OffCoder never receives the biometric template, an encoding of it, or any derivative thereof; the App receives only a boolean success/failure signal from the platform.

4. Network and runtime isolation

  • The PostgreSQL database is reachable only from backend application instances within the same VPC; it is not exposed to the public internet.
  • Cloud-runtime jobs execute inside Docker containers with constrained CPU and memory, dropped capabilities, and a non-root user. Network egress from runtime sandboxes is filtered to a small allow-list.
  • Each project's runtime sandbox is destroyed at job completion; there is no persistent state shared between users' jobs.

5. Operational hygiene

  • All administrative actions (account changes, refunds, plan grants, AI-flag resolutions) are written to an audit log retained for 18 months.
  • Production access is restricted by least-privilege role. Operational maintenance occurs over time-bound, audited sessions.
  • Dependencies are tracked, and high-severity CVEs are triaged within 7 days of publication.

6. AI-content safety

OffCoder operates two layers of content filtering on every AI request — a pre-prompt classifier and a post-output scanner — that block requests and responses falling within the categories prohibited by our Acceptable Use Policy (CSAM, malware, surveillance, weapons, illegal drugs). Every AI output carries a flag/report mechanism; flagged outputs go to an internal review queue and inform our filter improvements.

7. Vulnerability disclosure

If you believe you have found a security vulnerability in the OffCoder Service, please report it via email to security@offcoder.com. We commit to:

  • Acknowledge receipt within 3 business days.
  • Provide a triage update within 7 business days.
  • Where the report is in scope and reproducible, fix or mitigate within timelines proportionate to severity (critical: ≤7 days; high: ≤30 days; medium: ≤90 days; low: best-effort, generally rolled into a future maintenance release).
  • Credit the reporter in our advisories where they wish (and within the constraints of any active investigation).

We do not currently operate a paid bug-bounty programme; we may at our discretion offer goodwill compensation for reports that meaningfully improve the Service. Please give us a reasonable opportunity to investigate and remediate before public disclosure.

7.1 In scope

  • OffCoder mobile application — Android today (current and previous-but-one production version on Google Play); iOS where shipped, on the same scope basis.
  • api.offcoder.com, offcoder.com, admin.offcoder.com.
  • Hosted-service URLs of the form <handle>-<project>.offcoder.dev — for vulnerabilities in the platform itself, not user-published content.

7.2 Out of scope

  • Vulnerabilities in third-party services we integrate with (Razorpay, OAuth providers, AI providers, hosting providers) — please report those to the respective vendors.
  • Theoretical issues without a demonstrated exploit path.
  • Missing security or best-practice headers without a demonstrated impact (including, by way of example, missing X-XSS-Protection on browsers that have removed support for it, missing X-Permitted-Cross-Domain-Policies, weak referrer-policy combinations).
  • Missing or misconfigured email-authentication records (SPF, DMARC, DKIM) on a domain or sub-domain that does not actually send email.
  • Clickjacking or UI-redressing on pages that do not perform sensitive state-changing actions, and X-Frame-Options / CSP frame-ancestors findings against such pages.
  • Self-XSS (where execution requires the victim to paste payloads into their own console).
  • Descriptive error messages, version disclosure, or stack-trace leakage without a demonstrable secondary impact.
  • Missing rate limits or bruteforce protection without a demonstrated account-takeover or denial-of-service impact.
  • Password-policy reports (we do not maintain user passwords — see §3).
  • Reports generated by automated scanners without independent verification.
  • Social-engineering of OffCoder personnel, customers, or partners.
  • Denial-of-service testing or volumetric load testing without prior written agreement.
  • Findings against domains we do not own.

8. Incident notification

In the event of a confirmed personal-data breach we will notify affected users and the Data Protection Board of India (and, where applicable, EU/EEA supervisory authorities) within the timelines required by law (DPDPA: as soon as reasonably practicable; GDPR: 72 hours from awareness, where a notification is required). Users will be informed via the email on file, with a description of the incident, the personal data categories affected, the likely consequences, and the steps taken or planned in response.

9. Subprocessors and infrastructure

The current list of sub-processors, including the data categories shared with each, the regions in which they operate, and links to the underlying Data Processing Agreements, is maintained on our dedicated Sub-processors page. The corresponding contractual disclosures and rights are stated in Privacy Policy §7. We require contractually that sub-processors meet appropriate technical and organizational measures and that they notify us promptly of any incident affecting OffCoder data.

10. Contact

security@offcoder.com