Security Policy

Last updated: April 26, 2026

Security is a first-class concern for WooScraper. This page outlines what data we hold, how we protect it, and how to report a vulnerability if you find one.

1. What we store

• Account data: email address, name (optional), password hash, signup timestamp.
• Subscription state: plan, start date, end date, daily scrape counter, reminder flags.
• Payment records: reference code, amount, currency, method (UPI / USDT), status, and the subject line of the confirmation email used for verification.
• What we do not store: scraped product data is streamed to your browser and discarded server-side after the response. We do not retain a copy of any catalog you extract.

2. How we protect data

• TLS in transit. Every page and API endpoint is served over HTTPS with a managed Let's Encrypt certificate. HTTP requests are redirected to HTTPS.
• Password hashing. Passwords are hashed with bcrypt (cost factor 10). We never log, email, or display plaintext passwords.
• Session tokens. Authentication uses signed JWTs delivered as HttpOnly, SameSite=Lax cookies. The Secure flag is set in production so cookies cannot be transmitted over plain HTTP.
• Database isolation. SQLite data sits on an attached encrypted volume, accessible only to the application process inside the deploy container.
• Secret hygiene. JWT signing keys, the Gmail IMAP app password, and the mailer secret are stored as environment variables. None are committed to source control.
• Rate limiting. 60 requests/minute per IP on general endpoints; 20 requests / 15 minutes on authentication endpoints. Public detect endpoint is also rate-limited to prevent abuse.
• Security headers. Standard HTTP hardening via the helmet middleware (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, etc.).

3. Payment security

• We do not store card numbers, CVVs, or full bank details — we don't even accept card payments. Settlement is peer-to-peer via UPI or on-chain via USDT.
• Auto-verification works by parsing inbound bank/exchange notification emails over IMAP. The relevant fields (amount, reference code, sender) are extracted to update payment status; raw email bodies are not retained beyond the matching step.
• Receiving UPI IDs and USDT addresses are public information by design — exposing them does not put funds at risk.
• Each invoice carries a unique reference code. Reusing or guessing a code does not enable account takeover; verification additionally requires the amount to match.

4. What you can do

• Use a unique, strong password (we require ≥ 6 characters but we recommend 12+ with a password manager).
• Do not share your account credentials with anyone, including support staff. We will never ask for your password.
• Log out from shared or public devices when finished.
• Watch for phishing emails that impersonate WooScraper. Genuine emails come from @watshop.in; never click suspicious links.
• Report any unusual account activity to support@watshop.in immediately.

5. Reporting a vulnerability

If you believe you have found a security issue in WooScraper, please email support@watshop.in with the subject line "Security report" and include:

• A description of the issue.
• Steps to reproduce.
• Your assessment of impact.
• Optional: PoC code, screenshots, request/response captures.

Our commitments to good-faith researchers:

• We will acknowledge your report within 72 hours.
• We will investigate in good faith and keep you updated on progress.
• We will not pursue legal action against researchers who follow responsible-disclosure practices — no data exfiltration beyond what is needed to demonstrate the issue, no service disruption, and private disclosure to us first.

6. Incident response

If we discover a security incident affecting user data, we will:

1. Contain the incident and remediate the underlying cause.
2. Notify affected users by email within 72 hours of confirmation.
3. Publish a post-incident summary describing what happened, what data was affected, the timeline, and mitigations applied.

7. Out-of-scope

Reports that are typically not eligible:

• Best-practice configuration recommendations without a demonstrated vulnerability (e.g. "missing CSP header" with no exploit).
• Self-XSS or attacks requiring user-side compromise.
• Reports against third-party services we depend on (the underlying hosting provider, SQLite, etc.) — please report those upstream.
• Volumetric attacks (DDoS) and brute-force without an authentication weakness.

8. Changes

We will update this policy as our infrastructure evolves. Material changes will be announced by email or via a notice in the application.

Contact

support@watshop.in