Skip to content
WebCureby Swasti

How WebCure works.

Safe, scoped, read-only analysis by people who build SaaS apps themselves, on a schedule that keeps pace with your releases.

  1. 1

    Kick-off call & scope

    A 30-minute call. We note your stack, what's sensitive (payments, health data, AI features) and agree what we may test, in writing.

  2. 2

    Read-only access

    You share read-only access to your repo and a test account on staging or production. No passwords to your cloud console needed.

  3. 3

    First deep analysis

    Automated scans of code, dependencies, headers and cloud config, then manual testing of auth, access control, payments and AI features.

  4. 4

    Report & cure plan

    Within 7 days you get a severity-ranked report and a cure for every finding. Critical issues are sent to you on WhatsApp immediately, not at the end.

  5. 5

    Fixes & re-test

    You (or we, on Shield) apply the fixes. We re-test each one and update your security score.

  6. 6

    Ongoing watch

    Every month: a fresh scan, a threat update for your stack and any new findings from your latest releases.

Then it repeats, every month.

ScanReportCureRe-checkrepeatsevery month

  1. 1. Scan

    We analyse your live app, code and dependencies: automated scanners plus a human who thinks like an attacker.

  2. 2. Report

    A plain-English report ranked by severity, with the exact file, URL or setting and why it matters to your business.

  3. 3. Cure

    For every finding, a ready-to-apply fix: the code change, the setting to flip, or a pull request we open for you.

  4. 4. Re-check

    We verify each fix, then keep watching: new threats and new releases are checked every cycle.

Sample report

Plain English. Ranked by risk. A cure for everything.

Every finding says what we did, what it means for your business and exactly how to fix it, so you can hand it straight to whoever writes the code (or the AI that does).

Sample report · app.yoursaas.com

October · scan 4 of an ongoing Guard plan

Security score

9
Found
7
Cured
2
Open
CriticalWC-031 · GET /api/invoices/:id

Any signed-in user can read any team's invoices

What we did: signed in as Team B and requested invoice IDs belonging to Team A. All 20 requests returned full invoices, including billing addresses.

Business impact: customer data exposed to other customers; likely reportable as a data breach.

- where: { id }
+ where: { id, teamId: user.teamId }

Cure: one-line fix in app/api/invoices/[id]/route.ts · est. 10 minutes

Critical: fix todayHigh: fix this weekMedium: fix this month

What we check

  • Secrets in code, bundles and git history
  • Database rules (Supabase RLS, Firebase rules)
  • Login, sessions, OTP and password reset
  • Access control between users and teams
  • Admin areas and role checks
  • Payment flows and webhooks
  • AI features, tools and prompt injection
  • File uploads and storage buckets
  • Dependencies and known vulnerabilities
  • Security headers, CORS and cookies
  • Cloud and hosting configuration
  • Rate limits and abuse protection

What we never do

  • Denial-of-service or load attacks
  • Anything that deletes or changes real customer data
  • Testing apps you don't own or haven't authorised
  • Social engineering your team

Scope and permission are agreed in writing before any testing starts.

Ship fast. We'll keep it safe.

Send us your app's URL on WhatsApp. We'll scope a first analysis with you within a day.

Talk to us on WhatsApp