Loading scoping form…

Pen test scoping

Welcome to CyberGrid. To get the most out of your engagement, we need a few technical inputs from your team. Everything here is encrypted in transit and at rest, and only visible to the lead engineer on your engagement.

1. Target hosts & in-scope paths

Confirm the hostnames we should test. If you have an OpenAPI spec or GraphQL endpoint, give us the URL — we'll auto-build the authorization matrix from it.

Target hosts (one per line)

GraphQL endpoint (optional)

OpenAPI / Swagger URL (optional)

Tech stack (so we tune the test pack)

We'll auto-detect, but a one-line summary tightens our test selection.

2. Test accounts

We need at least 2 accounts (customer + admin) to run authorization, IDOR, and role-separation tests. If you can give us 3 (customer, second customer, admin), our IDOR coverage doubles.

3. JWT & session cookies (paste a working sample)

If you use JWTs, paste a working token from the customer-role login. We'll test alg=none, signature stripping, expiry enforcement, and claim manipulation against the JWT probe URL below. If you use session cookies, paste the Cookie header string from a logged-in request.

Sample JWT (customer role)

We never store this in plaintext on a long-lived disk — it lives in the engagement record encrypted at rest in our Neon Postgres.

JWT probe URL (the /me-style endpoint)

Session cookies — Cookie header string per host (JSON)

Open DevTools → Network → copy the Cookie header from any authenticated request. Put each host on its own key.

Roles cookies — for role-separation testing (JSON: role → cookie)

If you give us 2+ roles here, we run every admin-only path through every role and flag privilege-escalation gaps.

Second-account cookies (for IDOR replay)

Account B's session. We'll replay every authenticated GET as account B and flag cross-tenant reads.

4. Scope rules

Sqlmap is opt-in because it sends SQL payloads to real endpoints. Out-of-scope paths are never touched. Be explicit about anything destructive we must avoid.

Enable sqlmap on the URLs belowNon-destructive flags only (level=2, risk=1, technique=BEU). Detects but does not exploit.

Sqlmap targets — URLs with ? parameters to test (one per line)

Out-of-scope paths (one per line, glob OK)

Hard constraints (anything we must not do)

5. OAuth / OIDC (optional)

If your product uses OAuth (e.g. "Sign in with Google" on your customer portal, or you provide OAuth API access), give us the authorize endpoint and your registered client_id. We'll test for redirect_uri tampering, state CSRF, PKCE, and scope downgrade — non-destructive (we never complete the flow, just initiate it).

Authorize endpoint

Client ID (a test/non-prod client preferred)

Registered redirect URI (we use this as the exact-match baseline)

6. Race condition target (optional)

If you have an endpoint with a uniqueness constraint (one coupon redemption per user, single MFA enrollment, no double-billing), give us the URL. We'll fire 20 parallel requests with your customer cookie and report if more than one succeeded — a classic race window.

Race target — JSON: {"url":"...","method":"POST","body":{},"parallel":20,"expect_one_success":true}

We'll only fire 20 (or fewer if you specify) — no DoS. Pick something safely repeatable: a test-coupon endpoint, a quota-checked free-tier action, etc.

7. Anything else we should know

Known issues, specific risks you want us to focus on, places where you suspect things are weak — context helps us prioritize.

Your inputs save in one shot — you can edit and re-submit before the engagement starts.