Security
oddly is built by a security operator. Encryption, least-privilege access, audit-first design, and a responsible disclosure pathway are not retrofits; they are how the platform was put together.
Designed with PDPA, GDPR, and SOC 2 principles in mind. oddly is not yet formally certified to SOC 2 or ISO 27001. The control set we operate against, including access management, encryption, vendor management, audit logging, and incident response, is patterned on those frameworks. Formal attestation lands once the customer base justifies the cost.
Infrastructure
The Service runs entirely on Cloudflare's developer platform. There is no traditional server fleet to compromise.
- Compute. Cloudflare Workers and Cloudflare Pages Functions. Workers run in a V8 isolate sandbox; there is no shell, no filesystem to mount, and no persistent process to attack.
- Database. Cloudflare D1 (SQLite at the edge). Data is encrypted at rest. Backups inherit the same encryption.
- Object storage. Cloudflare R2 for assets. Encrypted at rest. Bucket policies default to private.
- Edge cache. Cloudflare's global CDN sits in front of every public surface. TLS termination happens at the edge.
- DNS + WAF. Cloudflare DNS with proxy on. Cloudflare's managed WAF rules are enabled, including the OWASP core rule set.
Encryption
- In transit. TLS 1.2 or higher for every public endpoint. HSTS is enabled. We do not accept plaintext connections.
- At rest. D1 storage is encrypted by Cloudflare. Backups are encrypted with the same scheme.
- Application secrets. OAuth refresh tokens, Stripe keys, webhook signing secrets, and dashboard tokens are stored in Cloudflare Workers Secrets. Secrets are write-only from the deploy pipeline; runtime code reads them only via the Workers binding API. They are never in source, never in logs, never in client-side JavaScript.
Authentication + access
- Connected sources. OAuth 2.0 to Shopify, Google Ads, Google Analytics, Google Search Console, and Meta Ads. Refresh tokens are scoped to the minimum required and stored encrypted at rest.
- Customer dashboard. Token-based authentication. Each merchant gets a dashboard token bound to their account; tokens can be rotated on demand.
- Stripe Customer Portal. Subscription management is handled in Stripe's hosted portal. Billing data and card details never reach our servers.
- Operator access. Two operators have administrative access to the platform. All admin actions are audit-logged. We do not have read access to OAuth refresh tokens at runtime; the application reads them via the Workers binding API and never returns them to a UI.
Webhook integrity
Every inbound webhook (Stripe, Shopify, Meta) is verified with an HMAC signature using Web Crypto before any side effect runs. Replays are dropped at the edge.
Action reversibility
Every change the platform writes to a Connected Source is recorded as an audit_entry with the action, actor, reasoning, and reversibility tag. Reversible actions can be rolled back from the dashboard.
Rate limits
Per-account and per-IP rate limits are applied at the edge. The action queue is independently capped per plan tier so a runaway script cannot exhaust your monthly action budget.
Log hygiene
Application logs are scrubbed of credentials, OAuth tokens, webhook signing secrets, and email payload bodies before being written. Server-side request logs are retained for 30 days for diagnostics.
Vulnerability management
- Dependencies are pinned. Automated scanning runs on every push to detect known CVEs in third-party packages.
- The platform is small (a few thousand lines of TypeScript). Code is reviewed before merge.
- The Cloudflare runtime patches itself; we inherit upstream fixes without operator intervention.
- No internet-exposed servers, no operating systems we maintain, no SSH access to remediate.
Operations + incident response
- Deploys. Pull-request review is required for all production changes. CI runs typecheck and lint on every push. Rollback is a single command via Cloudflare Pages history.
- Monitoring. Health checks run against the API surface. Webhook failure rates and action queue backlog are surfaced in an internal dashboard.
- Incidents. If a security incident affects customer data, we will notify affected customers within 72 hours of confirming the impact, in line with PDPA and GDPR breach-notification timelines.
- Backups. D1 supports point-in-time recovery. We maintain daily snapshots and have tested restore.
Subprocessors
The current subprocessor list and the data each handles is published in section 7 of the Privacy Policy.
Compliance posture
- PDPA (Singapore). The platform is operated from Singapore. PDPA obligations are honoured today: notification, consent, access, correction, withdrawal of consent.
- GDPR (EU). Where customers or their end-users reside in the EEA, GDPR-equivalent rights are honoured (access, rectification, erasure, portability, objection, restriction).
- Google API Services User Data Policy. oddly's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
- SOC 2. No formal attestation today. The control set is patterned on the SOC 2 Trust Services Criteria. We can share a control narrative under NDA on request to enterprise prospects.
- ISO 27001. No formal certification today. Roadmap item once the customer base justifies the audit cost.
Responsible disclosure
If you've found a security issue in oddly, please report it. We treat researchers as collaborators.
Where to send it
Email security@myoddlyeven.com. Subject line: SECURITY: followed by a one-line summary.
What to include
- A description of the issue and its impact.
- Steps to reproduce, ideally with a proof-of-concept that does not affect other customers' data.
- Your contact details and whether you'd like to be credited if the issue is confirmed.
What we commit to
- Acknowledge receipt within 3 business days.
- Triage and validate within 10 business days.
- Keep you updated on remediation progress.
- Credit you in the release notes when the fix ships, with your permission.
- Not pursue legal action against good-faith researchers who follow this policy and avoid harm to other customers.
Out of scope
- Denial of service. Please do not run load tests against the production environment.
- Social engineering of oddly staff or customers.
- Findings that depend on physical access to a user's device.
- Reports generated by automated scanners with no demonstrated impact.
Contact
Security: security@myoddlyeven.com.
General: subscriptions@myoddlyeven.com.