Web Security Scanner API

Name: Web Security Scanner API API
Brand: Web Security Scanner API
Availability: InStock

✓ Official Vendor SpecSecurityVulnerability Managementoauth211 EndpointsREST

For Agents

Configure and run dynamic security scans against Google Cloud-hosted web apps and pull XSS, mixed-content, and outdated-library findings. Read and write access to scan configurations and runs.

Quickstart

Get started with Web Security Scanner API in minutes using your preferred integration method.

# Add to your MCP client config (Claude Desktop, Cursor, Windsurf)
{
  "jentic": {
    "url": "https://api.jentic.com/mcp",
    "auth": "oauth"
  }
}

# Then ask your agent:
"start a web security scan and list findings"

# → Jentic returns the GET /events tool with parameter schema, agent executes.

Capabilities

What an agent can do with Web Security Scanner API API.

Create and update scan configurations targeting App Engine, Compute Engine, or GKE-hosted URLs

Start, stop, and list scan runs to perform on-demand or scheduled vulnerability scans

Retrieve findings filtered by type such as XSS, MIXED_CONTENT, or OUTDATED_LIBRARY

Inspect crawled URLs for a scan run to validate coverage of the target application

GET STARTED

Start building with Web Security Scanner API API

Explore with Jentic

View OpenAPI Document

Use for: Create a scan configuration for an App Engine application, Start a vulnerability scan on a registered scan config, List all findings of type XSS for the latest scan run, Retrieve aggregated finding-type statistics for a project

Not supported: Does not handle static code analysis, secrets scanning, third-party URL safety lookups, or scanning of non-Google-Cloud workloads — use for dynamic vulnerability scanning of App Engine, Compute Engine, and GKE web apps only.

The Google Web Security Scanner API automates dynamic application security testing for web apps running on App Engine, Compute Engine, and Google Kubernetes Engine. It crawls a target site, executes attack vectors against discovered URLs, and reports vulnerability findings such as cross-site scripting, mixed content, outdated libraries, and insecure cookies. Scans are configured as scanConfigs, executed as scanRuns, and produce findings and crawled-URL artefacts that can be retrieved for triage in CI or security dashboards.

Use Cases

Patterns agents use Web Security Scanner API API for, with concrete tasks.

★ Continuous DAST in CI

Trigger a Web Security Scanner run after every staging deploy of an App Engine or GKE app to catch newly introduced cross-site scripting, mixed content, and outdated library issues before production. The scan run is started through POST /v1/{+name}:start, and findings are pulled when the run finishes for upload to the team's defect tracker. This integrates cleanly with Cloud Build or any CI system that can hold an OAuth token for the project.

Start a scan run for the scan config named projects/{project}/scanConfigs/{id} via POST /v1/{+name}:start, poll until the run completes, then list findings of type XSS_CALLBACK and XSS_ERROR.

Security posture dashboard

Aggregate findingTypeStats across all scan runs in a project to display a top-line view of the most common vulnerability classes affecting an organisation's Google Cloud web apps. The endpoint returns counts grouped by finding type so dashboards do not have to fetch every finding individually. Combined with the Cloud Asset inventory, this gives security teams a coverage-versus-risk picture in one place.

Call GET /v1/{+parent}/findingTypeStats for a project and emit a CSV with finding type and count for each entry returned.

Coverage validation for crawls

After a scan, pull the list of crawled URLs to confirm that the scanner reached the intended application surface. This catches misconfigurations such as authentication walls or robots.txt rules that silently exclude pages from coverage. The crawledUrls endpoint returns the full list paginated; teams export this and diff against their URL inventory.

List crawledUrls for the most recent scanRun under a given scanConfig and flag any URL in the inventory that is missing from the crawled set.

Agent-driven scan triage through Jentic

A security agent connected through Jentic can pull findings, group them by severity, and propose remediation tickets without engineers writing direct API client code. The agent searches Jentic for list web security findings, loads the findings list operation, and executes it scoped to a scan run. Because the OAuth credential is held in Jentic, the agent never sees the raw token.

Through Jentic, list findings under scanRuns/{id} where findingType is OUTDATED_LIBRARY and produce a prioritised remediation list grouped by affected URL.

Key Endpoints

11 endpoints — the google web security scanner api automates dynamic application security testing for web apps running on app engine, compute engine, and google kubernetes engine.

METHOD

PATH

DESCRIPTION

GET

/v1/{+parent}/scanConfigs

List scan configurations

POST

/v1/{+name}:start

Start a scan run

POST

/v1/{+name}:stop

Stop a running scan

GET

/v1/{+parent}/findings

List findings under a scan run

GET

/v1/{+parent}/findingTypeStats

Get aggregated finding-type counts

GET

/v1/{+parent}/crawledUrls

List URLs crawled by a scan run

GET

/v1/{+parent}/scanConfigs

List scan configurations

POST

/v1/{+name}:start

Start a scan run

POST

/v1/{+name}:stop

Stop a running scan

GET

/v1/{+parent}/findings

List findings under a scan run

GET

/v1/{+parent}/findingTypeStats

Get aggregated finding-type counts

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

The OAuth 2.0 credentials for the Google Cloud project hosting the scanner are stored encrypted in the Jentic vault. Agents receive scoped access tokens; raw client secrets and refresh tokens never enter the agent's context.

Intent-based discovery

Agents query Jentic with phrases like start a vulnerability scan or list xss findings and Jentic returns the scanRuns:start or findings list operation with its input schema preconfigured.

Time to first call

Direct integration: 1-3 days including OAuth setup, scan-run polling, and finding pagination. Through Jentic: under an hour to run a scan and pull findings.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

Web Risk API

Checks third-party URLs for phishing and malware rather than scanning your own apps

Use Web Risk for outbound link safety and Web Security Scanner for inbound code-and-config vulnerabilities.

Complementary

Cloud Asset Inventory API

Catalogues all GCP resources so security tooling knows what exists to scan

Pair Cloud Asset (what we own) with Web Security Scanner (what is vulnerable) for full coverage reporting.

Complementary

Cloud Monitoring API

Alert on scan run failures and finding-count regressions

Push scanRun results into Cloud Monitoring so security regressions trigger paging just like SRE incidents.

FAQs

Specific to using Web Security Scanner API API through Jentic.

What authentication does the Web Security Scanner API use?

It uses OAuth 2.0 (Oauth2 and Oauth2c schemes in the spec) scoped to https://www.googleapis.com/auth/cloud-platform. Through Jentic the OAuth client credentials are encrypted at rest and short-lived access tokens are minted at execution; the agent never sees the underlying refresh token.

Can I scan apps that are not hosted on Google Cloud?

No. Web Security Scanner is designed for App Engine, Compute Engine, and Google Kubernetes Engine workloads accessible from Google's network. To scan apps hosted elsewhere, use a third-party DAST product. The scanConfigs resource validates the target URL belongs to a supported Google Cloud service.

What are the rate limits for the Web Security Scanner API?

Quotas are managed per Google Cloud project in the Cloud Console under APIs and Services. Scan runs themselves are throttled to avoid impacting the target application; the per-project default is documented in the Web Security Scanner pricing page. Most teams hit quotas on findings list calls during dashboard refreshes rather than on scan starts.

How do I start a scan run through Jentic?

Search Jentic for start a web security scan, load the schema for POST /v1/{+name}:start, and execute it with the scan config name in the form projects/{project}/scanConfigs/{id}. The response is a ScanRun object whose state field reports progress until it reaches FINISHED.

What finding types does the scanner detect?

The findings endpoint returns vulnerabilities including cross-site scripting (XSS_CALLBACK, XSS_ERROR), mixed content, insecure cookies, outdated libraries, and clear-text password transmission. Each finding includes the affected URL, request body, and reproduction steps. Filter by findingType when listing under /v1/{+parent}/findings.