Application Scanning

Overview

Application scanning performs Dynamic Application Security Testing (DAST) against your running web applications and APIs. Fencer crawls your application, discovers endpoints, and probes them for runtime vulnerabilities such as injection flaws, cross-site scripting, misconfigurations, and information disclosure. It can also scan an MCP (Model Context Protocol) server and inventory the tools, prompts, and resources it exposes.

Unlike code scanning, which analyzes source code at rest, application scanning tests your application as a real attacker would — over the network, against a live deployment. This catches issues that only manifest at runtime, including server misconfigurations and authentication bypasses.

Prerequisites

• At least one verified domain in your organization. All scan target URLs must belong to a verified domain.
• A valid subscription whose plan includes application scanning.
• For authenticated scanning, your plan must include the application scan authorization feature.
• Adding an application requires the assets:create permission (Administrator and Team Member roles).

How it works

When you add an application, you provide target information — specific URLs, a sitemap, an OpenAPI specification, a GraphQL endpoint, or an MCP server URL. For web applications and APIs, Fencer crawls the application (including pages rendered by JavaScript), discovers additional endpoints, and then runs both passive and active security checks against them. For an MCP server, Fencer connects to the server, inventories what it exposes, and flags dangerous items.

Each scan produces a scan record that tracks status, vulnerability counts by severity, and links back to the application asset. Results are compared against prior scans to classify findings as new, existing, or resolved — feeding into your vulnerability management workflow.

Scheduled scans run automatically for every application that is not suspended: daily or weekly (Mondays), depending on your plan.

Usage / Configuration

Adding an application

1. Go to Posture > Application (the page is titled Applications).
2. Click Add Application.
3. Under Scan Configuration, enter a Name and adjust Rate limit (req/s) (default: 20), Timeout (s) (default: 5), and Retries (default: 1) to control scan aggressiveness.
4. Under Define Scan Targets, choose a scan method (see below) and enter its target. Click one of your verified domains to pre-fill a target.
5. Optionally configure Authentication (see below).
6. Optionally adjust Criticality (0–100, default 100) and Compliance Scope.
7. Click Add Application. Fencer checks that the target is reachable and, when authentication is configured, that the credentials work; the save is blocked with a warning if either check fails. Once saved, Fencer automatically triggers an initial scan.

Scan methods

You must choose one of the following scan methods when configuring an application:

Method	Description
Manual URLs	Provide one or more specific URLs to scan. The scanner crawls from these entry points.
Sitemap	Provide a sitemap.xml URL. The scanner uses it to discover pages to test.
OpenAPI	Provide an openapi.json URL. The scanner imports the API specification and tests each endpoint.
GraphQL	Provide a GraphQL endpoint URL. The scanner introspects the schema and tests queries/mutations.
MCP	Provide your MCP server URL. The scanner inventories its tools, prompts, and resources and flags risks.

Note

The OpenAPI, GraphQL, and MCP scan methods require the application scan targets feature on your plan.

Authentication

By default, scans run without authentication. To test authenticated areas of your application, choose from the available authentication methods: No Auth, Basic Auth, Bearer Token, OAuth2 M2M, OAuth2, Custom Header, or Login Form.

For detailed configuration of each authentication method, see Authentication Configuration.

Caution

Authentication configuration requires the application scan authorization feature. If your plan does not include it, only unauthenticated scanning is available.

Triggering a scan

1. On the Applications page, find the application you want to scan.
2. Click Run scan on its row or tile, or on the application’s detail page.
3. Fencer queues the scan and begins processing.

Running a scan requires the scans:execute permission (Administrator, Team Member, and Penetration Tester roles).

Note

Run scan is disabled while a scan is already in progress. Manual scans are also throttled: if you trigger one too soon after the previous manual scan, you are asked to wait before retrying.

Reviewing an application

Open an application to see its overview, KPI cards (open vulnerabilities, targets, criticality, SLA status, and the last scan), and these tabs:

• Vulnerabilities — every open vulnerability found on the application, with the usual triage controls.
• Attack Surface — the endpoints the latest scan mapped, with a summary of how many endpoints were found, how many are sensitive, how many findings they carry, how many were confirmed attacked, and any known-exploited findings. Each endpoint shows its findings, request method and parameters, a Sensitive badge when its path matches a high-risk surface, and an Attacked badge when the scan confirms it probed the endpoint. Sort the list by Severity or Path. Notes explain when a narrowly scoped target limited the crawl, or when attack coverage could not be confirmed for every endpoint.
• MCP Surface — shown for applications that use the MCP scan method. For each MCP server it lists the Tools, Prompts, and Resources the server exposes, how many of each are dangerous, and marks individual items as Flagged or Deprecated with their issues.
• Trends & Remediation — once the application has more than one completed scan, this tab shows mean time to resolve, aging critical and high findings, how many open findings are Fixable now, regressions (resolved findings that reappeared), aging buckets, and a 90-day chart of open, new, and resolved findings.
• Scan Trust — whether the latest scan was Authenticated, failed to authenticate (Auth failed), ran Unauthenticated, or did not record an outcome; what the scan did (targets reached, endpoints crawled and attacked, and whether the crawl and active scan ran); and how fresh the results are. Results are marked Results may be stale when there has been no successful scan in the last 30 days.
• Scans — the application’s scan history.
• Settings — the application’s configuration (shown to users with the assets:edit permission).

Editing or deleting an application

• To edit, open the application’s Settings tab, update the scan configuration, targets, authentication, criticality, or compliance scope, and click Save Changes. Turn on Suspend Scanning to pause automated scans until you resume them.
• To delete, open the actions menu (⋯) in the application’s header, select Delete application, and click Delete. This removes the application and its scan data. Deleting requires the assets:delete permission (Administrator role).

Examples

Adding a sitemap-based scan

1. Go to Posture > Application and click Add Application.
2. Name the application “Marketing Site”.
3. Select the Sitemap scan method.
4. Enter https://www.example.com/sitemap.xml.
5. Leave authentication as No Auth.
6. Set Rate limit (req/s) to 10 to avoid overloading the server.
7. Click Add Application. The initial scan starts automatically.

Adding an authenticated API scan

1. Go to Posture > Application and click Add Application.
2. Name the application “Internal API”.
3. Select the OpenAPI scan method.
4. Enter https://api.example.com/openapi.json.
5. Set authentication to Bearer Token and provide your API token.
6. Click Add Application. The scanner imports the API spec and tests each endpoint with authentication.

Troubleshooting

• “Please wait X more minutes before triggering another manual scan” — Manual scans are throttled. Wait for the cooldown to expire before retrying.
• Target URL rejected — All target URLs (including sitemap, OpenAPI, GraphQL, and MCP URLs) must belong to a verified domain in your organization. Add and verify the domain under Posture > Domains first.
• Save blocked with a reachability or credentials warning — Fencer could not reach the target, or the configured credentials were rejected. Fix the URL or credentials and save again.
• Authentication feature not available — Authenticated scanning requires the application scan authorization feature on your plan. Contact your administrator to upgrade.
• Scan finds no vulnerabilities — Check the Scan Trust tab to confirm the scan reached its targets and, if you use authentication, that it signed in. Verify that the target URLs are reachable from Fencer’s scanning infrastructure — see Allowlisting Scanner IPs.

Related pages

• Authentication Configuration
• Vulnerability Management
• Domain Attack Surface