test-red-team — Adversarial Full-App Defect Sweep

The job is not done when the code compiles or even when the happy path works. It is done when a hostile, skeptical attacker has tried every angle — UI/UX, data pipeline, security, and performance — and the defect list is in the user's hands. This skill exists because nobody ships a perfect first pass. Red teaming finds the gaps before real users do.

This skill produces a defect list. Unlike test-playwright (fix-as-you-go PDCA), the default output is a severity-ranked report, not inline fixes. Offer to fix after the report is delivered; ask which defects to prioritize.

Before ANY browser action, read `protocol-browser-anti-stall` (`~/.cursor/skills/protocol-browser-anti-stall/SKILL.md`) and apply every rule — especially Rule 0 (manual & headed, never scripted). Also read references/playwright-session-coordination.md — shared browser, tab discipline, persisted auth.

Attack through the visible UI, by hand. Drive a headed browser one real action at a time. Code execution (browser_evaluate / CDP / WebView attach) is allowed ONLY to set a condition (throttle network, kill a request, emulate a device) or inspect state — never to perform the click/type/submit you're attacking. The defect must be reachable the way a real attacker or user reaches it.

Coverage model

Do NOT do a blind structural DOM crawl — that is test-qa. Traverse a coverage matrix instead:

feature/capability
  → surfaces (routes, sub-pages, API endpoints, RPCs, tables)
    → components + states (forms, tables, modals, empty/error/loading, role variants)
      → 4 attack dimensions: UI/UX · data pipeline · security · performance

Each cell in the matrix (feature × surface × component-state × dimension) is marked PASS / DEFECT / N-A. The matrix is both the traversal plan and the audit trail in the final report.

Graceful fallback: if no discernible features exist (pure marketing site), degrade to route → component structural traversal.

Phase 0: Scope & rules of engagement

0a. Detect the stack

package.json             → framework, auth, ORM, RN/Expo, test port
capacitor.config.ts/.json → Capacitor hybrid (web + native shell)
app.json / app.config.*  → Expo / React Native
android/                 → native Android target

Record:

• Target type: web-only | RN/Expo | Capacitor hybrid | mixed monorepo
• Dev URL / port (scripts.dev, default 3000 / 5173 / 8081)
• Auth pattern (Supabase Auth, NextAuth, Clerk, custom JWT)
• Test credentials (.env.local, .env.test, README)
• Backend MCPs available: Supabase (plugin-supabase-supabase), Sentry

(plugin-sentry-sentry), Firecrawl (user-firecrawl)

0b. Pick the automation driver

0c. Capacitor WebView attach (when target includes Capacitor)

Exception to Rule 0: a native WebView can't be driven by snapshot-ref tools, so attaching is the only option here. Once attached, still interact like a user (tap, type, scroll) — don't script the flow end-to-end. Ensure the app is running, then:

const { _android } = require('playwright');
const [device] = await _android.devices();
// requires: ADB device online, Chrome ≥ 87, WebView debuggable flag
const webview = await device.webView({ pkg: 'com.your.app.id' });
const page = await webview.page();
// page is a standard Playwright Page — all browser MCP methods apply

For native chrome outside the WebView, fall back to adb shell input tap with coordinates from adb shell uiautomator dump.

0d. Rules of engagement

• All test data prefixed RT-TEST- for easy cleanup
• Do NOT mutate production data; ask before any non-reversible operation
• Confirm exploits with evidence; no destructive PoCs against real rows
• Secrets referenced by name only — never printed in chat

0e. Browser session (before Phases 2–5)

Read protocol-browser-anti-stall/references/playwright-session-coordination.md.

1. browser_tabs list → claim auth tab or open new tab for your sweep.
2. Reuse Google/OAuth/email session via storage state — sign in once, save to

.playwright-mcp/auth/<host>.json, update session.json.

1. Work only in your tab; never close tabs another agent may be using.
2. Do not log out between attack phases unless testing logout/session fixation.

Phase 1: Recon & build the coverage matrix

Before opening the browser, build the matrix from source code. This is the most important phase — the matrix determines what you attack.

1a. Enumerate features / capabilities

Sources to check (read, do not shell-grep unless necessary):

1b. For each feature, decompose

Feature: [name]
  Surfaces:
    - Routes/pages: [list]
    - Sub-pages / deep links: [list]
    - API endpoints / RPCs called: [list]
    - DB tables touched: [list]
  Components + states:
    - [component name]: states=[default, empty, loading, error, role-A, role-B, ...]
    - Forms: [list fields + validation rules]
    - Modals / drawers: [list + triggers]
    - File upload surfaces: [list]
  Roles / tenants:
    - [role list — anon, user, admin, org-member, etc.]
  Input surfaces (for injection testing):
    - [input fields, URL params, query strings, headers, file content]

1c. Output the matrix

Print the matrix before starting Phases 2–5. Example:

COVERAGE MATRIX
| Feature       | Surface/Component+State          | UI/UX | Pipeline | Security | Perf |
|---------------|----------------------------------|-------|----------|----------|------|
| Auth          | Login form / empty               |       |          |          |      |
| Auth          | Login form / error (wrong creds) |       |          |          |      |
| Documents     | List page / empty state          |       |          |          |      |
| Documents     | List page / 100+ items           |       |          |          |      |
| Documents     | Create modal / all fields        |       |          |          |      |
| Documents     | Share flow / other-user role     |       |          |          |      |
...

Fill each cell with ✅ PASS / ❌ DEFECT(#N) / — N-A as you work through Phases 2–5.

Phase 2: UI/UX red team (per matrix cell)

For each cell, navigate to the surface, reach the component state, and attack.

Driver: Playwright browser MCP tools — browser_navigate, browser_snapshot, browser_take_screenshot, browser_click, browser_type, browser_fill_form, browser_console_messages, browser_network_requests, browser_resize.

Per cell checklist:

Capture a browser_take_screenshot as evidence for every DEFECT. Note the component file path if identifiable from the DOM or source tree.

Phase 3: Data pipeline red team (per matrix cell)

Every mutation surface (create / update / delete / upload) gets attacked here.

Verify mutations at 3 layers: (1) UI feedback, (2) network call, (3) DB row.

DB verification via Supabase MCP

Look up the tool schema first:

CallMcpTool(server: "plugin-supabase-supabase", toolName: "list_tables", arguments: {
  "project_id": "<PROJECT_ID>"
})

Then verify the mutation:

CallMcpTool(server: "plugin-supabase-supabase", toolName: "execute_sql", arguments: {
  "project_id": "<PROJECT_ID>",
  "query": "SELECT * FROM <table> WHERE <col> LIKE 'RT-TEST-%' ORDER BY created_at DESC LIMIT 10"
})

RLS role verification (confirm what the client can actually read/write):

CallMcpTool(server: "plugin-supabase-supabase", toolName: "execute_sql", arguments: {
  "project_id": "<PROJECT_ID>",
  "query": "SET ROLE authenticated; SELECT * FROM <table> WHERE user_id != auth.uid() LIMIT 5"
})

Attack patterns

Supabase logs check

After running attack patterns, pull API + postgres logs:

CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_logs", arguments: {
  "project_id": "<PROJECT_ID>",
  "service": "api"
})

Flag any unexpected 5xx, unhandled exceptions, or RLS deny events.

Supabase advisors

CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_advisors", arguments: {
  "project_id": "<PROJECT_ID>"
})

New ERROR-level advisors count as pipeline defects.

Phase 4: Security red team (per matrix cell, OWASP-mapped)

Full payload tables and OWASP/MASVS mapping: references/owasp-attack-checklist.md.

Priority order (highest real-world impact first):

Correlate with Sentry (search 401/403/CSP violations last 30 days) and research current OWASP guidance via Firecrawl.

Phase 5: Performance red team (per matrix cell)

Focus on the conditions real users hit: cold start, slow network, large data.

Network throttling

Condition-setup only — throttling can't be done by clicking. Set the condition via Playwright's CDP layer, then drive the actual load/scroll/submit by hand:

// Simulate Slow 3G
const client = await page.context().newCDPSession(page);
await client.send('Network.emulateNetworkConditions', {
  offline: false, downloadThroughput: 50 * 1024 / 8,
  uploadThroughput: 20 * 1024 / 8, latency: 300
});

On Capacitor/Android, use adb shell tc qdisc add dev wlan0 root netem delay 300ms.

Attacks per surface

Supabase query performance

CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_advisors", arguments: {
  "project_id": "<PROJECT_ID>"
})

Advisors flag missing indexes, sequential scans on large tables, and bloated RLS policies. Each is a Medium–High performance defect.

Phase 6: Finding-chaining & triage

Before writing the report, scan all DEFECT cells for chains:

• Two Medium findings often combine into a High or Critical path.

Example: "reflected input in URL param" + "CSP missing" = stored XSS → data theft.

• Auth weakness + IDOR = full account takeover chain.
• Stale cache + no optimistic revert = silent data corruption.

For each finding, assign:

Phase 7: Defect report (the deliverable)

## Red-Team Defect Report — [App / Repo] — [Date]

### Scope
- Target type: [web | RN | Capacitor | mixed]
- Dev URL: [...]  Auth: [...]
- Features red-teamed: [list]
- Coverage matrix: [link or inline]

### Critical Defects (fix before any release)
| # | Feature | Surface / Component+State | Finding | Evidence | File | Remediation |
|---|---------|--------------------------|---------|----------|------|-------------|
| 1 | Auth | Login / error state | IDOR: User B can read User A documents via GET /api/docs/:id | Screenshot+network | src/app/api/docs/[id]/route.ts | Add ownership check: `WHERE user_id = auth.uid()` |

### High Defects
| # | Feature | Surface / Component+State | Finding | Evidence | File | Remediation |

### Medium Defects
| # | Feature | Surface / Component+State | Finding | Evidence | File | Remediation |

### Low / Info
| # | Feature | Surface / Component+State | Finding | Evidence | File | Remediation |

### Attack chains identified
1. [Finding #N] + [Finding #M] → [combined impact and attack path]

### Coverage matrix (final)
| Feature | Surface/Component+State | UI/UX | Pipeline | Security | Perf |
|---------|------------------------|-------|----------|----------|------|
...

### Backend truth-check
- Sentry: [new/related issues — count + highest severity]
- Supabase: [advisors, logs, RLS test results]

### Launch-readiness verdict
**Ready / Ready after Critical fixes / Not ready** — [2-sentence justification]

### Test data cleanup
- RT-TEST-* rows deleted: [Y/N / N-A]

Guardrails

1. Manual & headed, never scripted — attack through the visible UI one real action

at a time; code execution is for condition-setup/inspection only, not for driving the click/type/submit under test; no *.spec.ts, no npx playwright test.

1. Anti-stall always — never block >3 s on a browser action; incremental

wait → snapshot → check; max 4 attempts per goal; mark [TIMEOUT] and move on.

1. Evidence for every DEFECT — screenshot + console + network + DB query

result. "It looked broken" is not a defect.

1. No destructive PoCs — confirm XSS/SQLi with a benign payload

(document.title='XSS', SELECT 1), never DROP TABLE or real data exfil.

1. Ask before mutating production rows — DDL (schema changes) for a requested

fix ships; DELETE/UPDATE/TRUNCATE on real production data asks first.

1. Secrets by name only — never print .env values in chat or screenshots.
2. Honest verdict — do not declare "no defects" if any cell is untested. Mark

untested cells N-A with a note explaining why (auth blocked, no data, etc.).

1. Offer to fix after the report — ask which Critical/High defects to address

first; use test-playwright PDCA discipline when applying fixes.

1. MCP schemas first — always check tool schemas under mcps/<server>/tools/

before calling any MCP tool.

1. Pure-native iOS/Android out of scope — document it in the report if relevant.