anyshop.io

anyshop.io Security Policy

Status: draft. Publish-ready at V0 launch. Last updated: 2026-05-11. Companion documents: TERMS.md, PRIVACY.md, AUP.md, ARCHITECTURE.md.

1. Why this document exists

If you are a security researcher, an enterprise seller's IT team, a PSP underwriter, or anyone else who needs to know what anyshop.io does about security: this is the document. It is short on purpose. The full architecture is in ARCHITECTURE.md; this document is the surface anyone can read in five minutes.

2. How to report a vulnerability

Contact

  • Email: security@anyshop.io
  • Optional encryption: PGP key fingerprint published at anyshop.io/.well-known/security.txt (V0 launch)
  • In-product: "Report a security issue" in the dashboard footer

What to send

  • A clear description of the vulnerability
  • Steps to reproduce, including any test accounts or payloads you used
  • The impact you observed (data exposure, privilege escalation, denial of service, etc.)
  • Your name and a way to credit you publicly if you'd like (optional)

What we promise

  • Acknowledgment within 48 hours
  • First substantive response within 5 business days
  • Decision and timeline for fix within 14 days of confirmed report
  • Patch deployed before public disclosure, except in cases of active exploitation
  • No legal action against good-faith researchers who follow the rules in §3
  • Credit in our public security changelog if you want it; anonymity if you prefer

Coordinated disclosure

Standard 90-day window from confirmed report to public disclosure, extendable on mutual agreement if a fix takes longer. Sooner if the bug is being actively exploited.

3. Rules for good-faith research

You're welcome to test our platform within these guardrails. We won't pursue legal action against research that stays inside them.

Allowed:

  • Testing on your own account or accounts you've explicitly been granted permission to use
  • Standard web app testing — XSS, CSRF, IDOR, authn/authz issues, SSRF, business-logic flaws
  • API fuzzing within your own scope
  • Reviewing client-side code, our public docs, our public REST API
  • Reporting findings privately to security@anyshop.io

Not allowed:

  • Accessing or attempting to access data belonging to other sellers or buyers
  • Denial-of-service attacks against our infrastructure
  • Social engineering of anyshop.io employees, contractors, or customers
  • Physical attacks on infrastructure
  • Testing against production payment flows with real cards (use Stripe test cards)
  • Automated scanning that generates more than ~10 requests per second from a single IP without contacting us first
  • Public disclosure before we've had a chance to fix the issue

If something you're considering isn't clearly on either list, email us first and ask.

4. Scope

In scope:

  • anyshop.io and any *.anyshop.io subdomain we operate
  • dashboard.anyshop.io, api.anyshop.io, *.anyshop.io storefronts
  • Our REST API at api.anyshop.io/v1/* and api.anyshop.io/dev/v1/*
  • Our outbound webhook signing and delivery
  • Sellers' storefronts hosted on custom domains we provision

Out of scope:

  • Third-party services we use: Stripe, PayPal, Clerk, Neon, Resend, Sentry, Cloudflare, Vercel, PostHog, BTCPay. Each has its own security program — report there.
  • Seller-uploaded content (descriptions, themes a seller has heavily modified, files they're selling). Sellers are responsible for the content of their stores.
  • Stripe Connect onboarding flows. Stripe-hosted; not our codebase.
  • Issues that require physical access to a seller's device
  • Issues that require a compromised email account or device of the seller as a prerequisite
  • Best-practice findings without a demonstrable impact (e.g. "missing HSTS preload" — useful, but not a vulnerability)
  • Rate limits in our public API. We rate limit; that's not a bug.
  • Self-XSS — XSS that requires the victim to paste a payload into their own browser console
  • Findings only reproducible in EOL browsers (we support last 2 versions of evergreen browsers)
  • Issues already reported by another researcher (we credit first reporter)

5. What we do (security commitments)

This is what we commit to building and maintaining. Items marked (V0) are in place at launch; (V1) is committed for after launch; (target) is a goal without a date.

5.1 Transport and edge

  • TLS 1.2+ everywhere, TLS 1.3 preferred — (V0)
  • HSTS with preload on all our owned domains — (V0)
  • Strict Content Security Policy with nonce-based script execution — (V0)
  • Cloudflare Turnstile on all checkout pages and high-risk forms — (V0)
  • Cloudflare DDoS protection at the edge — (V0)
  • Rate limiting on auth, checkout, and API endpoints — (V0)

5.2 Authentication and session

  • Authentication via Clerk — battle-tested provider, regular audits — (V0)
  • Passkey / WebAuthn support for sellers — (V0)
  • Authenticator-app 2FA for sellers — (V0)
  • OAuth (Google, Discord) — (V0)
  • Magic-link for buyer customer portal — (V0)
  • Session timeouts (24h sliding, 30d absolute for seller; 7d for buyer) — (V0)
  • Active session manager — sellers can review and revoke all sessions — (V0)
  • Critical-action re-authentication — password changes, 2FA changes, payment provider rotation require fresh auth — (V0)

5.3 Data isolation

  • Per-shop scoping on every database query, enforced in Drizzle middleware — (V0)
  • Per-account scoping on top of per-shop — (V0)
  • API key → scope → query enforcement — keys can't escape their assigned scope — (V0)
  • Shared Postgres at V0 with row-level filtering; tenant-isolated databases evaluated at scale — (target)

5.4 Data at rest

  • AES-256 encryption for sensitive fields: license keys, PSP credentials, API key tokens, webhook signing secrets — (V0)
  • API keys stored as SHA-256 hashes — raw token shown only once on creation — (V0)
  • PII minimization — we collect what we need to operate, nothing more — (V0)
  • Backups encrypted at rest by Neon — (V0)

5.5 Webhooks

  • HMAC-SHA256 signed outbound webhooks — (V0)
  • Timestamped signatures to prevent replay (5-minute tolerance) — (V0)
  • Per-webhook signing secret, rotatable from the dashboard — (V0)
  • Inbound webhook verification for Stripe, PayPal, BTCPay signatures — (V0)

5.6 RBAC and audit

  • Granular per-manager permissions (~25 switches across orders, products, customers, etc.) — (V0)
  • Process-amount cap per manager to limit insider-fraud blast radius — (V0)
  • Comprehensive audit log of every state change, exportable — (V0)
  • Manager session tracking in the audit log with IP and user-agent — (V0)

5.7 Anti-fraud

  • Stripe Radar on all card payments going through seller's Stripe Connect — (V0)
  • Velocity rules per email, per IP, per device — (V0)
  • 9-dimension blocklist (IP, range, email, domain, country, city, ASN, ISP, plus all-aggregate) — (V0)
  • VPN/proxy detection on checkout (per-product configurable) — (V0)
  • Disposable-email blocking on signup and checkout — (V0)
  • Platform-wide 1.5% chargeback ceiling with automatic seller suspension — (V0)

5.8 Monitoring

  • Sentry for error tracking with EU data residency — (V0)
  • Vercel Analytics + PostHog for performance and product analytics — (V0)
  • Internal alerting on anomalies (signup spikes, error rates, chargeback rate per shop) — (V0)
  • Status page at status.anyshop.io — (V0)

5.9 Incident response

  • Defined IR process documented internally — (V0)
  • Breach notification within 72 hours to affected users and regulators (GDPR requirement) — (V0)
  • Public post-mortems for significant outages — (V0)
  • Runbooks for common incident types — (V1)

5.10 Vendor management

  • DPAs signed with all processors handling personal data — (V0)
  • Annual processor review — (V1)
  • No new processor added without policy update and seller notice — (V0)

5.11 Source code and CI/CD

  • Code review required on all changes to production branches — (V0)
  • Dependabot / similar on all dependencies — (V0)
  • Secrets in Vercel env vars + secret manager, never in code — (V0)
  • Preview deployments isolated from production data — (V0)
  • Annual third-party penetration test — (target — V1+)

5.12 Compliance

  • GDPR-aligned data handling — (V0)
  • CCPA-aligned for California buyers — (V0)
  • PCI scope minimization — we never see PAN data; Stripe handles it on our or seller's behalf — (V0)
  • SOC 2 Type II — (target — when enterprise demand justifies)

6. Threat model

The threats we explicitly defend against, in rough order of impact-likelihood weight:

6.1 Insider seller fraud

A seller uploads stolen credit cards, runs them through their own Stripe Connect, and steals license-key inventory or causes chargebacks for the platform.

Defenses: 1.5% chargeback ceiling with auto-suspension. Stripe Radar at the PSP layer. AUP §4.4 prohibits multiple accounts. Audit trail. Manual fraud review for sellers in higher-risk categories (game keys, trading signals).

6.2 Buyer-side fraud (carding, stolen cards)

A buyer with a stolen card buys a product, gets the license key delivered immediately, then the cardholder chargebacks. Seller loses the product + the chargeback fee.

Defenses: Stripe Radar primary. Our velocity rules, VPN/proxy block, disposable-email block, blocklist. The seller's per-product block_vpn and block_disposable toggles. The seller can also set warranty_days = 0 to refuse refunds beyond chargeback. We do not platform-fund refunds, so we have no direct exposure — but high seller chargeback rates are platform-poisoning for our PSP relationships.

6.3 Multi-tenancy bleed (one seller sees another seller's data)

The catastrophic platform-level bug. Per-shop scoping enforced in the ORM layer, defense-in-depth via API-key scope enforcement, end-to-end integration tests on tenant isolation.

6.4 Credential theft / account takeover

Seller email/password compromised; attacker drains license-key inventory or changes payment-provider connection to redirect funds.

Defenses: Passkeys + 2FA mandatory beyond a credential-only login for production. Critical-action re-auth on payment-provider rotation. Email alerts on suspicious sign-ins. Active session manager.

6.5 Inbound webhook spoofing

Attacker POSTs forged Stripe / PayPal events to fake an order being paid, triggering license-key delivery.

Defenses: Strict signature verification on every inbound webhook. Mismatched signatures rejected and logged. Sentry-monitored. Never trust the body of a webhook for funds-confirmation without verifying the signature.

6.6 Outbound webhook abuse

A seller's webhook URL is configured to a victim domain; seller asks us to fire test events to DoS the victim.

Defenses: Reasonable rate limit on test-fire (e.g. 10/min/webhook). The webhook URL is the seller's own; we are not the attacker. We do not allow webhook URLs to private IPs or to anyshop.io subdomains.

6.7 Storefront SSRF / file delivery abuse

Seller uploads a product "file" that is actually a script designed to be executed by us, or sets a delivered_message that probes our infrastructure when rendered.

Defenses: Files are stored as blobs and served from Vercel Blob — never executed. Delivered messages are rendered as text with HTML escaped or via a strict allowlist. CSP prevents script execution from blob URLs.

6.8 License-key theft

Insider (anyshop.io employee or compromised admin) or attacker gains read access to the database and exfiltrates license keys.

Defenses: Keys encrypted at rest with a separately-managed KMS key. Decryption logged in audit trail. Internal access to production data is gated and logged. We never have a single employee who can both read DB and read KMS keys without a paired action.

6.9 Subscription billing abuse

Attacker creates many free-trial accounts to use the platform indefinitely without paying.

Defenses: Disposable-email block, one trial per email + per IP, Stripe Connect onboarding ties the account to a real identity, signup velocity limits. Trial accounts have lower rate limits than paying accounts.

6.10 Theme XSS (post V0)

When the Monaco theme editor ships in V1, malicious theme code could try to execute on buyer browsers. Mitigated by sandboxing in a content-iframe with a separate origin and a strict CSP. Out of V0 scope.

7. What we don't claim

In the interest of honesty:

  • We are not SOC 2 certified at V0. We follow SOC-2-aligned practices but have not undergone the audit.
  • We do not have a 24/7 SOC. We have on-call engineers and Sentry alerting; that is not the same as a staffed security operations center.
  • We do not run a paid bug bounty. We acknowledge and credit researchers; we may offer rewards on a discretionary basis. A formal bounty program is planned post-V1 once we have stable surface area.
  • We have not commissioned a third-party penetration test. V1 target.
  • Our threat model assumes our PSPs (Stripe, PayPal) and our infrastructure provider (Vercel) are not compromised. Defending against a compromised vendor is beyond our scope.

8. Public security artifacts

At V0 launch, we publish:

  • anyshop.io/.well-known/security.txt — contact, encryption key, scope, ack policy
  • anyshop.io/security — public version of this document
  • status.anyshop.io — uptime and incident page
  • anyshop.io/changelog/security — chronological record of fixes and credits

9. Hall of fame

Researchers who report valid vulnerabilities and consent to being credited are listed at anyshop.io/security/hall-of-fame (V0 launch). Empty at the time of writing.

10. Contact

PGP fingerprint and public key: anyshop.io/.well-known/security.txt.

11. Open items before publication

  1. Generate and publish PGP key + security.txt
  2. Confirm whether we run a paid bounty at V0 (recommendation: no — wait for V1 surface stability)
  3. Decide on monitoring SLO targets to commit to publicly (uptime, MTTR for security incidents)
  4. Set up status.anyshop.io (Vercel offers a status integration; Statuspage.io is the gold standard)
  5. Internal IR runbook for the most common scenarios (lost-laptop, leaked-credential, vendor-compromise, exfiltration alert)

Security — last updated 2026-05-12. Questions? legal@anyshop.io