Security

In scope

• wer.org — the apex marketing site and operator dashboard host
• app.wer.org — the operator dashboard
• *.wer.org — tenant subdomains (storefronts)
• Operator custom domains routed through Approximated to our infrastructure
• Our public APIs (/api/*, pricing feed at /sell/feed.json, etc.)

Out of scope

• Third-party platforms we depend on — Supabase, DigitalOcean, Stripe, Resend, Approximated, EasyPost, Cloudflare. Report those to the vendor directly.
• Issues already fixed in the latest release of one of our dependencies (e.g. an old Next.js CVE we’ve already patched).
• Denial-of-service, volumetric, or rate-limit testing without prior written agreement. Don’t.
• Social engineering of our staff, vendors, or operators.
• Issues that require physical access to a device.
• Self-XSS, missing best-practice headers without a demonstrated exploit, missing rate limits without a demonstrated exploit.

What we ask of you

• Don’t exfiltrate or modify data. Prove the bug with a single benign read (e.g. whoami, your own row in a table you shouldn’t see). Don’t dump production data.
• No DoS testing. Don’t flood, scan with high concurrency, or attempt to crash services.
• No phishing or social engineering against our staff, partners, or operators.
• Coordinated disclosure. Give us a reasonable window to fix before publishing. We aim for 30 days; longer for issues that require coordinated upstream patches (e.g. a Next.js CVE).
• Test only against your own account or a fresh trial. Don’t target other operators’ storefronts or seller data.

What you can expect from us

• Acknowledgment of your report within one business day.
• An honest assessment of impact and our planned timeline.
• Notification when the issue is fixed and deployed.
• Public credit on this page if you’d like (and a polite no-thanks if you’d prefer to stay anonymous).

We do not currently run a paid bug-bounty program. If your finding is high-impact and you’d like to be paid for your time, mention it in the email and we’ll discuss what makes sense — but please don’t lead with a payment demand.

Hardening already in place

What we do today, so you can focus your testing on areas that might actually have gaps:

• Postgres Row Level Security on every tenant-scoped table with FORCE ROW LEVEL SECURITY.
• Service-role database access wrapped in an audited helper that records every privileged read/write to audit_events.
• IMEIs and payout details encrypted at rest with PostgreSQL pgcrypto; reveals are audit-logged; auto-purged at 12 months.
• Application logs scrub 14–16 digit numeric strings to prevent IMEI leakage.
• Magic-link authentication only — no passwords stored.
• Edge-trust model: custom-domain requests must transit a known proxy (Approximated) with a shared edge token; direct DigitalOcean hits to custom domains are rejected.
• TLS 1.2+ everywhere, HTTP redirected at the edge.
• Reserved-slug + profanity blocklist on tenant signup.

Acknowledgments

As of May 2026, no public acknowledgments yet. The first researcher whose report ships a meaningful fix gets named here.