Help us find your pages

When AlertaVuln runs a hosted DAST scan, it starts at your target’s home page and follows the links it finds. That works for a server-rendered site, but two very common shapes give the crawler nothing to follow:

• Single-page apps (React, Vue, Angular, Svelte) ship an almost-empty HTML shell and build the page in the browser. The crawler fetches the shell, finds no <a href> links to the real routes, and scans only the landing page.
• APIs have no HTML and no links at all. Without a map of endpoints, the scanner has nothing to probe.

In both cases the scan comes back nearly empty - not because your app is clean, but because the scanner never reached the pages that matter. Seeding fixes that: you hand the scan a starting map - a list of URLs, an OpenAPI spec, or both - and it scans everything on the map instead of guessing from links.

Note

Seeding is part of the hosted (“Scan it for me”) flow, an Enterprise feature. A self-hosted av dast scan from your own machine can seed the same way with flags - see From the CLI below.

Where to enter it

In the web app, open the Dynamic Scan page for your project and find the Scan it for me panel. Each target has a Help us find your pages section with two inputs:

1. Page & entry URLs - a list of URLs the scan should visit, one per line. Give it the routes a crawler can’t discover: your SPA’s main views, deep links, and anything not linked from the home page.

2. OpenAPI / Swagger spec - the address of your API’s machine-readable description, or the spec itself pasted in. The scan reads every path and method from it and probes them directly.

Provide either one, or both. For a typical SPA-with-an-API you’ll want both: the URL list covers the browser-rendered pages, and the spec covers the API behind them.

Find your OpenAPI / Swagger spec

Most API frameworks already generate an OpenAPI (formerly Swagger) document - you often just need to know its URL. Here’s the default location per framework:

FastAPI

FastAPI serves the spec automatically:

https://api.example.com/openapi.json

The Swagger UI at /docs and ReDoc at /redoc both read that same file. If you mounted the app under a path or set root_path, the spec moves with it (e.g. /api/openapi.json).

ASP.NET Core

With Swashbuckle the JSON document is at:

https://api.example.com/swagger/v1/swagger.json

The Swagger UI at /swagger loads it. With NSwag the default is /swagger/v1/swagger.json as well. If you version your API the v1 segment changes per document.

Spring Boot

With springdoc-openapi on the classpath:

https://api.example.com/v3/api-docs

The Swagger UI at /swagger-ui.html reads it. Add .yaml for YAML output (/v3/api-docs.yaml).

NestJS

With @nestjs/swagger, wherever you called SwaggerModule.setup('api', ...) the raw document is served with a -json suffix:

https://api.example.com/api-json

(If you set up the docs under docs, the spec is at /docs-json.)

Express

Express doesn’t generate a spec on its own. If you use swagger-jsdoc + swagger-ui-express, expose the generated object as its own route:

// where swaggerSpec is the object from swagger-jsdoc
app.get('/openapi.json', (req, res) => res.json(swaggerSpec));
app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(swaggerSpec));

Then seed with https://api.example.com/openapi.json.

Django REST

With drf-spectacular, wire up the schema view and point at it:

https://api.example.com/api/schema/

That returns YAML by default; the Swagger UI at /api/schema/swagger-ui/ reads the same schema.

Rails

With rswag, the generated Swagger file is served from the docs mount, typically:

https://api.example.com/api-docs/v1/swagger.yaml

The exact path is whatever you set for swagger_endpoint / the docs route.

Go

With swaggo (swag init + a UI handler like gin-swagger), the generated JSON is served next to the UI:

https://api.example.com/swagger/doc.json

Already have a Swagger UI page?

If you can open an interactive API docs page in your browser, the spec is right there. Open your browser’s DevTools -> Network tab and reload the docs page: the request that returns a big JSON (or YAML) body - usually named openapi.json, swagger.json, or api-docs - is the spec. Copy that URL, or save the response and paste it into the panel.

If you paste instead of linking

You can paste the spec’s JSON or YAML straight into the panel instead of giving a URL. Do that when the spec isn’t reachable from the public internet - for example it’s only served behind your VPN, requires a login to fetch, or you generate it at build time and never host it. A pasted spec is used as-is; the scan doesn’t need to fetch it.

No OpenAPI spec at all?

If your API has no spec, you don’t need to invent one. List your key endpoints as Page & entry URLs instead - one URL per line, including the method’s path and any required query string. The scan probes each URL you list. It’s more work than a spec, but it gets the important endpoints covered.

Build a URL list

For the Page & entry URLs box, you’re after the routes a link-follower would miss. Good sources:

• Your SPA’s router. The route table (React Router, Vue Router, Angular routes) is the definitive list of client-side views. Turn each route into a full URL: /dashboard, /orders/123, /settings/profile.
• A sitemap. If you publish https://example.com/sitemap.xml, it already lists your canonical URLs - copy them in.
• Key deep links. Anything you’d bookmark: a specific report, a search results page with a representative query, an item detail page.

You don’t need every URL - a handful of representative pages per section is usually enough for the scanner to exercise the app. Use real IDs that exist in the environment you’re scanning (staging), not placeholders.

Same site only

Every seed URL and OpenAPI address must be on the same site as the target - the same registrable domain (subdomains are fine: api.example.com seeds are valid for a example.com target). Off-site URLs are rejected so a scan can’t be pointed at a domain you haven’t proven you control. This mirrors the domain-verification gate that authorizes the scan in the first place.

Pair it with authentication

Seeding tells the scan where to look; authentication lets it in. If the pages and endpoints you seeded sit behind a login, set up an Authenticated scan on the same target (a bearer token, header, or cookie) so the scanner sends credentials with every request. Without it, seeded URLs behind a login just return the sign-in page and the scan still finds nothing.

A spec plus a token is the strongest combination for an API: the spec maps every endpoint, and the token gets the scanner past the auth wall to actually exercise them.

From the CLI

A self-hosted av dast scan seeds the same way, with flags instead of the panel:

av dast scan --target https://staging.example.com \
  --seed-urls ./urls.txt \
  --openapi https://staging.example.com/openapi.json

• --seed-urls takes a file with one URL per line (the Page & entry URLs equivalent).
• --openapi takes a spec URL or a local file path (the OpenAPI / Swagger spec equivalent).

The same same-site rule applies: URLs outside the target’s registrable domain are dropped. See av dast scan for the full flag list.

See also

• Run DAST scans from the CLI - the self-hosted path, start to finish.
• Dynamic scanning (DAST) - what DAST covers, and how hosted scanning works.
• av dast targets auth - set up authenticated scans behind a login.
• av dast scan - every flag, including --seed-urls and --openapi.