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