Authenticated DAST Scanning

Configure Sectora to crawl the protected surface of your application — not just the public-facing pages.

Why this matters

Most real vulnerabilities live behind authentication. A scanner that only sees your sign-in page misses ~60% of the attack surface. Sectora supports four authentication strategies so the scan reaches the same routes your real users do.

Pick your strategy

Configure the strategy on the Authentication step of the new-scan dialog.

1. Form login (cookie-based)

Classic username/password POST. Use this when your app has a server-rendered login form. Sectora fetches the form to discover the CSRF token, posts your credentials, and harvests the resulting Set-Cookie header. The cookie is reused across the crawl + refreshed automatically when it expires.

  • Session Cookie (optional) — paste a pre-obtained cookie if you don't want Sectora to perform the login itself.
  • Login URL — the form's action URL.
  • Login Method — usually POST.
  • Login Payload — JSON ({"email":"x","password":"y"}) or form-encoded (email=x&password=y). CSRF token is auto-injected if discovered.
  • Auth verify URL — a URL that requires login (e.g. /dashboard). Sectora probes it every 5 minutes; if you get kicked out mid-scan, Sectora re-runs the login automatically.

2. OAuth 2 / OIDC (Bearer token)

For apps protected by Google, Microsoft, Okta, Auth0, Keycloak, or any RFC-6749-compliant IdP. Sectora obtains an access token via one of three grants and injects it as Authorization: Bearer ... on every request.

Setup:

  1. Go to Settings → Auth Profiles → New.
  2. Choose oauth2 as the type and fill in: Token URL, Client ID, Client Secret, Scope.
  3. Pick a grant type:
    • client_credentials — 2-legged, service-to-service.
    • refresh_token — you supply a long-lived RT obtained out-of-band.
    • authorization_code — complete the browser consent flow once via the “Initiate OAuth Flow” button; Sectora stores the resulting RT and refreshes it automatically.
  4. Click Test on the profile to confirm token acquisition works.
  5. On the new-scan dialog, set Authentication strategy to OAuth 2 / OIDC and pick the profile.

Token refresh happens transparently across long scans — Sectora caches the access token and refreshes a minute before expiry. PKCE is enabled by default for authorization_code; mTLS client certificates can be added on the same profile for IdPs that require them.

3. SAML SSO

Coming soon. The strategy slot is reserved; full implementation pending the headless-browser integration that drives the IdP login.

4. Session import — the gray-box pen-test path (CAPTCHA / MFA / SSO)

This is the strategy for a gray-box penetration test: you hand Sectora a real, already-authenticated session, and it attacks your app as that logged-in user — crawling the protected UI and running the OWASP API Top 10 suite (IDOR/BOLA, broken auth, mass assignment, injection) against the exact API calls your app makes behind login. Use it for targets behind a CAPTCHA/Turnstile, 2FA, WebAuthn, or SSO, where automated credential replay is fragile. You log in once in your own browser (passing the bot-check and MFA there); Sectora only ever receives the resulting session. No passwords, MFA codes, or CAPTCHA challenges ever reach Sectora.

Option A — Browser extension (recommended)

The Sectora Session Capture extension is the one-click way to hand off a session — no scripts, no copy-paste. From the new-scan dialog:

  1. Enter your target URL (step 1), then on the Authentication step choose Session import.
  2. Click Capture with extension. If the extension isn't installed yet, the button links you to install it (Chrome/Edge); install once and click again.
  3. A capture is armed for your target host. In your own browser, open the target app and log in normally — solve the CAPTCHA, complete MFA/SSO, whatever it takes. This all happens in your browser.
  4. Click the Sectora extension icon → Capture & send. It grants access to that single host, reads the post-login cookies (incl. httpOnly) + localStorage, and posts the session straight back to your scan. The dialog flips to captured.
  5. Click Start Scan. Sectora runs the gray-box scan with that session.

Security model: the extension does a Sectora login of its own — none. The only authorization is a single-use, target-scoped token (10-minute expiry) minted by your already-authenticated dashboard. It ships with zero host permissions and requests access to just the one target host at capture time; it reads cookies + localStorage after you log in and never touches form fields, keystrokes, or the page DOM. The armed request lives in session storage and is wiped on capture or browser close.

Option B — Manual export (no extension)

Capture the session yourself as a Playwright storageState (cookies + per-origin localStorage) and paste/upload it:

  • With Playwright — run a one-off script that opens a browser, lets you log in by hand, then writes the state:
    // node capture.js  —  npm i playwright
const { chromium } = require('playwright');
(async () => {
  const ctx = await (await chromium.launch({ headless: false })).newContext();
  const page = await ctx.newPage();
  await page.goto('https://app.example.com/login');
  console.log('Log in (incl. MFA), then press Enter here...');
  await new Promise(r => process.stdin.once('data', r));
  await ctx.storageState({ path: 'storageState.json' });
  console.log('Saved storageState.json'); process.exit(0);
})();
  • Then in the new-scan dialog, choose Session import and upload (or paste) storageState.json.

Before use, Sectora scopes the imported cookies and localStorage to the scan target's host (off-target credential material is dropped). The blob is stored encrypted at rest with the scan. At scan start Sectora probes your target with the imported session; if it is already expired the scan is recorded as verify_failed rather than reported as authenticated (best-effort — a fully public target root cannot be distinguished from an authenticated one). Because there are no stored credentials to re-authenticate with, an imported session cannot be auto-refreshed — if it expires mid-scan the remainder runs logged-out and auth_status reflects it. Pick a fresh, long-lived session and keep large scans within its lifetime. Treat the export like a password: re-capture rather than reusing an old file.

If your target sits behind a WAF

A gray-box scan still sends real attack traffic, which a WAF (Cloudflare, AWS WAF, Akamai) will often block — and the scan will report "Scan coverage incomplete — N% of requests blocked by WAF". For full coverage of your own app, allowlist Sectora's scanner: all scans egress from a single static IP shown under Settings → Scanning. See Scanning a site behind a WAFfor the per-WAF allowlist steps. A WAF blocking the scanner doesn't mean the app is safe — it means those endpoints couldn't be reached to be tested.

How re-authentication works

Sessions expire. A typical scan lasts 10 minutes to a few hours; many session cookies expire in 15-60 minutes. Sectora's SessionManager:

  • Probes your Auth verify URL every 5 minutes.
  • Detects logged-out signals: 401, redirect to /login, login-form HTML on a previously-protected page.
  • Re-runs the login flow on detected expiry, with throttling (60s floor between attempts, 5-attempt cap).
  • Refuses to follow logout URLs (/logout, /signout, framework-specific paths for Devise/Django/Spring/Auth0/Keycloak/Okta) so the crawler can't foot-gun its own session.

The scan's auth_status column is updated continuously; at the end of every scan you can see whether the session held up.

Troubleshooting

  • Scan says auth_status=login_failed — check the Login Payload field shape. JSON needs the right field names; form-encoded needs application/x-www-form-urlencoded shape. Set an Auth verify URL so Sectora can confirm the post-login state.
  • OAuth token errors — open the AuthProfile detail page; the “Last test status” field shows the IdP's response. invalid_grant on a refresh_token grant means the IdP revoked your RT — re-initiate the Authorization Code flow.
  • Scan ran unauthenticated — confirm the new-scan dialog showed the strategy as configured (the “Authentication” chip on the scan card). If you selected OAuth2 but no profile, the scan returns a 503 dispatch_failed.

Security

All auth material (cookies, OAuth client secrets, refresh tokens, mTLS keys) is encrypted at rest with a per-deployment key held in our secrets vault. Tokens are decrypted only in memory at scan time. AuthProfiles are RLS-scoped so one customer cannot read another's. Every reveal or rotation of an OAuth refresh token is audit-logged.