# External pentest scope — v2026 (v1.0.9 pre-launch audit)

> **Engagement period** : v1.0.9 W5-W6 (per `docs/ROADMAP_V1.0_LAUNCH.md` §Day 25). Async work, ~10 business days.
> **Authorisation** : signed scope letter + NDA on file (see "Legal context" below).
> **Re-test** : one re-test included after the team's fix pass.
> **Contact** : `security@veza.fr` ; PGP key fingerprint published at `https://veza.fr/.well-known/security.txt`.

This brief is the technical hand-off for the external pentest team. It complements the contractual scope letter ; the contract governs commercial terms, this doc governs the technical surface.

## Engagement summary

**Target** : Veza, an ethical music streaming platform. Backend is Go 1.25 + Gin + GORM ; streaming is Rust + Axum ; frontend is React 18 + Vite. Infrastructure is Incus (LXD) on a single self-hosted R720 in v1.0, moving to a multi-host Hetzner topology in v1.1.

**Version under test** : v1.0.9 (release candidate for v2.0.0 public launch). Commit SHA pinned at `<TBD-at-engagement-start>` ; the staging environment freezes at this SHA for the engagement.

**Goals** :

1. Find what the internal pre-flight audit (`docs/SECURITY_PRELAUNCH_AUDIT.md`, W5 Day 21) missed — focus on business-logic abuse paths the automated scanners can't model.
2. Validate the v1.0.9 surface added since the last review : DMCA workflow, marketplace pre-listen, embed widget, WebRTC ICE config, faceted search.
3. Assess the multi-tenant invariants (creator vs. listener vs. admin) under malicious user input.

## In-scope assets

| Asset                           | Endpoint / surface                                              | Notes                                                |
| ------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------- |
| **Backend API**                 | `https://staging.veza.fr/api/v1/*`                              | All v1.0.9 endpoints + the OpenAPI spec at `/swagger` |
| **Stream server**               | `https://staging.veza.fr/api/v1/tracks/*/hls/*`                 | HLS-only — RTMP ingest is out (v1.1)                 |
| **Embed widget**                | `https://staging.veza.fr/embed/track/:id`                       | Public iframable HTML, OG tags                       |
| **oEmbed**                      | `https://staging.veza.fr/oembed`                                | JSON envelope                                        |
| **Status / health**             | `https://staging.veza.fr/api/v1/status`, `/health`              | Public ; intentional disclosure                      |
| **Frontend SPA**                | `https://staging.veza.fr/`                                      | React 18 + Vite ; sourcemaps available on staging    |
| **WebSocket (chat / live)**     | `wss://staging.veza.fr/api/v1/ws`                               | Protocol described in `docs/api/websocket.md`        |
| **Marketplace**                 | `/api/v1/marketplace/{products,orders,licenses,reviews}`        | Hyperswitch sandbox, no real card processing         |
| **DMCA workflow**               | `POST /api/v1/dmca/notice` + admin queue                        | Sworn-statement validation, audit log, takedown gate |

## Out of scope

- **Production** (`api.veza.fr`, `app.veza.fr`). Engaging prod is not authorised — every test runs against staging.
- **Third-party services we don't operate** : Hyperswitch live mode, Bunny.net edges, Sentry, Forgejo. Their security posture is the providers' responsibility.
- **Denial-of-service testing** above the rate-limiter quotas. The platform's rate-limit middleware is in scope ; sustained flooding to deplete bandwidth is not.
- **Social engineering against Veza staff.** Phishing simulations require a separate engagement with prior written authorisation.
- **Physical / wireless** attacks against the R720 lab.
- **Source-code modification** : the engagement is grey-box (source available read-only at `https://10.0.20.105:3000/senke/veza` once the pentester's IP is allow-listed) but findings must be reproducible against staging without local patches.

## Authentication context

Three test accounts pre-seeded on staging :

| Role         | Email                       | Password                | Notes                                  |
| ------------ | --------------------------- | ----------------------- | -------------------------------------- |
| Listener     | `pentest-listener@…`        | `<delivered out-of-band>` | role=user, no 2FA, fully-verified      |
| Creator      | `pentest-creator@…`         | `<delivered out-of-band>` | role=creator, owns 5 seed tracks       |
| Admin        | `pentest-admin@…`           | `<delivered out-of-band>` | role=admin + MFA bypass token         |

Bearer tokens for synthetic-client style testing are derivable from `/api/v1/auth/login`. All passwords are randomised per-engagement and rotated immediately after the engagement ends.

## High-priority focus areas

We're particularly interested in the following surfaces (in order of impact). The internal audit cleared the trivial OWASP-Top-10 hits ; here we want creative attacks.

### 1. Authentication + session lifecycle

- JWT key rotation : staging uses RS256 with `JWT_PRIVATE_KEY_PATH`. Can the public key be inferred from misconfigured JWKS-style endpoints ?
- 2FA bypass : the login flow returns `requires_2fa=true` on partial-auth. Is there a state-machine flaw between partial-auth and full-auth ?
- Refresh-token replay after logout : revocation list is Redis-backed. What happens if Redis is partitioned ?
- Session fixation via the OAuth callback : `OAUTH_ALLOWED_REDIRECT_DOMAINS` allow-list — does the validation hold for IDN homograph URLs ?

### 2. Payment / marketplace

- Order tampering : the `POST /api/v1/marketplace/orders` body contains product IDs + quantity. Can a buyer craft an order at an arbitrary price ? (Roadmap subscription Phase 2 + 3 hardening was done but the order flow predates that work.)
- Webhook signature replay : `POST /webhooks/hyperswitch` validates a signature. Does the implementation check timestamps, or only the HMAC ?
- Refund window race : `RefundDeadline` is set to `+14d` on order completion. What happens if the buyer initiates a refund at exactly `14d - 1ms` and the validation race is exposed ?
- Pre-listen abuse : `?preview=30` is anonymous-OK when `products.preview_enabled=true`. The 30 s cap is **client-side** (HTML5 audio currentTime) ; can an attacker grab the full audio via byte-range requests despite the gate ? (Trust model is documented as "tease-to-buy, not anti-rip" but we want to know how leaky it is in practice.)

### 3. DMCA workflow

- Notice forgery : `POST /api/v1/dmca/notice` is public + rate-limited. Can the rate-limit be bypassed via header rotation, X-Forwarded-For spoofing, or IPv6 prefix walking ?
- Sworn statement bypass : the `sworn_statement: true` field is trusted. Can a malformed JSON body land a notice with `sworn_statement` absent (Go's zero-value) ?
- Admin takedown enumeration : `GET /api/v1/admin/dmca/notices` returns paginated pending notices. Does the offset+limit handling leak a separate-tenant's claimant data ?

### 4. Upload + transcoder pipeline

- Chunked upload state pollution : `POST /api/v1/tracks/upload/initiate` allocates an upload_id. Can two users with the same upload_id collide on the chunked-state Redis keys ?
- File-type confusion via `Content-Type` : the upload validator checks magic bytes. Are there codec-level flaws (e.g. malformed FLAC header that crashes the transcoder) ?
- HLS segment poisoning : the streamer caches segments by track_id. Can a crafted upload pollute another track's cache via path traversal in the segment filename ?

### 5. WebRTC ICE config + embed

- The `/api/v1/config/webrtc` endpoint is intentionally public per `SECURITY_PRELAUNCH_AUDIT.md`. We want a second opinion on whether the short-lived TURN credentials are short enough.
- Embed iframe XSS : `/embed/track/:id` interpolates `track.title` + `track.artist` into HTML body + OG tags via `html.EscapeString`. Try crafted Unicode + HTML-entity edge cases (e.g. surrogates, RTLO, byte-order marks).
- oEmbed URL injection : `?url=` is parsed for `/tracks/<uuid>`. Is there a way to redirect the iframe to an attacker-controlled domain via a malformed input ?

### 6. Faceted search + share tokens

- SQL injection via the search facets : `genre`, `musical_key` are bounded by length but passed as parameterised values. Verify parameterisation holds end-to-end.
- Share-token enumeration : the W5 Day 21 audit unified error responses to a single 403. Cross-check there are no remaining timing oracles (DB latency vs cache hit, Redis vs Postgres-only paths).

## Internal audit — already fixed (skip these)

The W5 Day 21 audit already addressed the items below. They're listed so the external doesn't waste time re-reporting them.

| Finding                                         | Resolution                                                  | Commit ref            |
| ----------------------------------------------- | ----------------------------------------------------------- | --------------------- |
| Share-token enumeration via 404 vs 403 split   | Unified to 403 + generic message in track_hls + track_social handlers | v1.0.9 W5 Day 21 |
| XSS via track metadata in embed widget          | `html.EscapeString` wraps every HTML interpolation          | v1.0.9 W3 Day 15      |
| DMCA workflow XSS via `work_description`        | Storage parameterised, render is React-escaped              | (audit, no code change) |
| `/config/webrtc` disclosure                     | Accepted by design, short-lived TURN credentials            | (audit, accepted)     |

## Reporting protocol

- **Severity scale** : CVSS 3.1. Critical (9.0+), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9), Informational.
- **Reporting cadence** : ad-hoc for Critical/High (within 4 business hours of confirmation), batched daily for Medium and below.
- **Channel** : encrypted email to `security@veza.fr`. PGP key at `https://veza.fr/.well-known/security.txt`. For Critical findings, also use the Signal contact in the engagement letter.
- **Format** : per finding — title, severity, CVSS vector, reproduction steps (curl / browser-side script), proof of exploitation, recommended remediation, affected component(s).
- **Status calls** : weekly 30-min check-in (calendar invite from `security@veza.fr`).

## Re-test

The engagement includes one re-test. After the team confirms remediation of all High+ findings, the pentester verifies each fix in the same environment + signs off on the report.

## Legal context

- Authorisation letter on file : signed by `<CEO name>` for Veza, signed by `<lead pentester>` for the firm. Effective `<start date>` to `<end date + 30 d for re-test>`.
- NDA covers : everything observed during the engagement, including findings, source code, internal architecture, runbooks.
- Logs : Veza retains all server-side logs for 30 d post-engagement so the team can reconstruct any reported finding without relying on the pentester's local notes.
- Incident-response coordination : if the pentester believes they've triggered a real incident (e.g. accidentally took staging down beyond the agreed scope), they ping `security@veza.fr` immediately ; we coordinate a controlled rollback per the canary release runbook (`docs/CANARY_RELEASE.md`).

## What we'll do with the report

- **Critical / High** : fix before the v2.0.0 public launch. The launch GO/NO-GO checklist (W6 Day 26) blocks on these.
- **Medium** : fix in v2.0.x patch releases.
- **Low / Info** : tracked in the `docs/SECURITY_PRELAUNCH_AUDIT.md` follow-up table for the next review cycle.
- **Public credit** : the firm's name in `docs/SECURITY_ACKNOWLEDGEMENTS.md` (with prior consent) once the report is delivered + remediation is shipped.

## Files for the pentester's first day

- `docs/ROADMAP_V1.0_LAUNCH.md` — what shipped in v1.0.9 + the launch acceptance bar.
- `docs/SECURITY_PRELAUNCH_AUDIT.md` — internal audit findings + resolutions (skip these in the external).
- `docs/api/` — OpenAPI / Swagger generated from the live source ; `https://staging.veza.fr/swagger` mirrors it.
- `docs/CANARY_RELEASE.md` — how the team rolls fixes during the engagement (so the pentester can predict re-test windows).
- `infra/ansible/` — read-only via the Forgejo allow-list ; gives architectural context.

## Acceptance gate (Day 25 internal milestone)

- [ ] Pentester briefed (this doc + scope letter handed off)
- [ ] Staging access provisioned + test accounts delivered out-of-band
- [ ] Source-code repo allow-list includes pentester's static IP
- [ ] Initial check-in scheduled
- [ ] Internal audit findings (W5 Day 21) confirmed fixed in the staging build the pentester is testing