A regular scan looks at your app from the outside. A web-app scan goes inside: it crawls a verified web asset and runs active tests (injection, cross-site scripting and the rest of its dynamic checks) over every unique page it finds. It runs only when someone on your team starts it, never on a schedule, and it is part of every plan.

Before You Start

The asset must be verified and active. FortWatch tests only what you have proven you own.
Use a test or staging environment when you can. The scan sends the requests an attacker would.
For a signed-in scan, create a dedicated test account. The scan can do whatever that account can do, so never use an admin account.

Run a Public Scan

Open the asset and find the Web-app scan tab.
Tick the consent box: FortWatch may crawl this asset and send test requests to the pages it finds.
Click Scan web app. The scan's live activity shows the crawl and the tests as they run.

Without form testing, the scan sends only GET requests, so it cannot create, change or delete data. The crawl stays on the asset's host and never follows logout or delete links. A large site is reduced to its unique pages, so the whole meaningful surface gets tested within the time limit instead of the same template a thousand times.

Add a Login for the Signed-In Area

Most of an app lives behind its login. Attach one test-account login to the asset, on the same tab:

Form login — the login page, the username and password field names, and the account's username and password. FortWatch fills in the real form in a browser.
Session cookie — a cookie value you paste.
Header — a value sent in a header you name, such as Authorization: Bearer ….

Every login also names an entrypoint (a page that shows the account signed in), a logout URL that is never visited, and a logged-in pattern: text only a signed-in page shows. The password or token is sealed when you save it and never shown again.

Click Save & verify login. FortWatch signs in, checks that the pattern appears, that it did not land back on the login page and that the session works in a fresh browser, and shows you a screenshot. If the screenshot shows the account signed in, click Yes, this is signed in. Nothing runs signed in until a person confirms it.

Run a Signed-In Scan

With a confirmed login, the scan card offers one more tick: also scan the logged-in area as that account. A signed-in run signs in fresh, never stores the session, starts its crawl at the entrypoint, and leaves the logout URL and the login page alone. It reads signed-in pages and submits no forms behind the login. If the login fails, the scan stops and says so, with the failure screenshot. It never falls back to a public scan, so a scan that never got past the login page cannot read as clean.

Form Testing (Opt-In)

Tick Also submit this app's forms to test the app's safe forms, such as contact and search. FortWatch submits only ordinary forms on the asset's own host, with clearly labelled test values, and skips anything destructive or sensitive: delete, payment, checkout, unsubscribe, logout, password and file-upload forms. A contact form will receive a batch of labelled test messages. Form testing and the signed-in scan are separate runs.

What You Get

What the scan finds becomes ordinary issues, with evidence, an SLA and alerts. A finding from a signed-in or form-testing run is marked as such, and its issue tells you to re-run that kind of scan to confirm a fix, because a nightly scan cannot see behind your login. A run cut short by its time limit, or throttled by your site's rate limiting, is marked partial, never clean.

Limits Today

Two-factor sign-in, one-time codes, CAPTCHA and single sign-on on another host are not supported. Use a test account without them, or a session cookie or header.
One login per asset.
Web-app scans run on demand; they are not part of scheduled scans.

← Previous

Interpreting Scan Results

API Scanning from an OpenAPI Description