Google Web Security Scanner API

Name: Web Security Scanner 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.

Install Jentic One Beta

Connect the Web Security Scanner API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Web Security Scanner API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Web Security Scanner 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

GET STARTED

Start building with Web Security Scanner API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use Web Security Scanner 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 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.

FAQs

Specific to using Web Security Scanner 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.

Google Web Security Scanner API

Connect the Web Security Scanner API to your agent

Capabilities

Start building with Web Security Scanner API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs