As a new user of AppCheck, setting up scans might appear complex or perhaps even overwhelming (especially for scans relating to web applications). This guide aims to teach you the basics of creating such scans. Once you are more familiar with the process, you should find in the vast majority of cases, it is both relatively straightforward and won't take up too much time.

This guide only describes the initial steps required whilst setting up a scan. Any settings which are not explicitly mentioned in this guide can safely be left with their default values.

1. Determine the Type of Scan
2. Prerequisites
3. Basic Settings
   1. Create a New Scan
   2. Add Scan Targets
   3. Notifications
   4. Scheduling
   5. Scanning Hub
   6. Save
4. Advanced Settings
   1. Authentication
   2. Optimisations
5. Further Reading

Determining the Type of Scan

The first consideration when creating a scan should be the type of scan target. Is your target an item of infrastructure (such as a server or laptop), a web application, or an API? This guide covers scanning web applications. Please see How to Scan: APIs or How to Scan: Infrastructure to learn how to create scans for APIs or infrastructure targets respectively.

For more general information on the different types of scan targets, see 3 Types of Scanning - Port Scanning, Web Application Scanning, and Infrastructure Scanning.

It is extremely common to combine both types of scan as a way of adding extra value - your web application scan may also include a small infrastructure scan, or your infrastructure scan may include one or more small web application scans. 

The important question we are asking at this stage is what will be the primary target of your scan: is it a web application (including APIs) or an item of infrastructure?

• A web application scan target will always take the form of a URL, and will always be accessed over HTTP or HTTPS.  http://example.com and https://api.example.com are web application scan targets.
• example.com is not a URL, it is simply a fully qualified domain name - it does not identify a web application, it identifies a server, and as such would be an infrastructure scan target.
• ftp://example.com/ is a URL, but it does not use HTTP or HTTPS, and so is not a valid scan target.

Your application may be made up of multiple parts, such as the front-end and the API, e.g. https://www.example.com and https://api.example.com, which must both be accessed together to use the application. Is this case, both web application targets should be added to the same scan.

If your API is not called directly from the end-user's browser, but is instead called by your front-end application server, then it does not need to be included in the scan - only the components accessed by the end-user need to be included in the scan.

Once you have determined that your main target is a web application, you can proceed to set up a scan.

Scan Prerequisites

In most cases, the only essential prerequisite is access from the scan hubs to your scan targets:

• If your targets are available over the public internet then you can use AppCheck's Public Scan Hubs. See Allowing AppCheck Access to Your Network or Applications.
• If you are scanning a target that is not available over the public internet then you will need to purchase and install a Private Scan Hub. Contact your account manager to purchase one, and then to set one up follow the Private Scan Hub Setup Guide.
• If your application contains an authentication barrier then you may wish to configure a user for the scanner to log in with. See Selecting an Account for your Authenticated Web Application Scan.

Basic Settings

Creating a New Scan

From the left hand navigation pane in the AppCheck Scanner Portal, choose the Standard or Single-Page Application option:

• Scans
  • New Scan
    • Web Application
      • Standard or Single-Page Application

Give Your Scan a Name

In the New Scan Advanced form which appears, enter a descriptive name for the scan using whichever naming convention works best for you.

We strongly recommend not including the scan target URL in the name.  The scan name may be included in notification emails from the Scanner in the form of links which point to the Scanner Portal - when your email client detects a hyperlink where the text is a URL and that URL differs from the link target the email client may identify the email as malicious.  Including the hostname should be safe, so you may simply wish to remove the scheme, for example use example.com instead of https://example.com.

Adding Scan Targets

Add the Primary Scan Target

Enter your scan targets in the Targets field:

For convenience, the targets registered with your account are listed within the Scanner Scope panel accessible on the right hand side. This allows you to easily copy and paste targets into the Targets field.

Your targets will be colour-coded to indicate the type of target (you may need to press enter to complete adding a target).  By default, when you add a web application scan target, e.g. https://example.com, the corresponding infrastructure targets are added automatically (e.g. example.com).  This is normally desirable, since it might reveal vulnerabilities in the environment the application is running within alongside findings from the application itself. If you do not wish to utilise this feature, you can simply remove any corresponding infrastructure targets you don't wish to scan.

Considering Additional Scan Targets

Additional targets to consider including in your scans might include:

• The API(s) associated with the application.
• The Content Management System (CMS) associated with the application.
• Subdomains used as part of the application (e.g. https://account.example.com).

The additional scan targets you include will be crawled within a single browser session. There are two main reasons to do this:

1. Endpoint Discovery - It may not be possible to crawl one of your targets on its own, but its endpoints can be discovered when interacting with another target.  For example: crawling your front-end application may be the only way to discover your API endpoints and files hosted in your CMS platform.
2. Authentication - Access to one of your targets may require authentication, and the easiest way to gain authentication is through another target.  For example, it may not be possible to make requests to your API without first opening an authenticated session via the front-end application.

When we refer to a web application scan target, we are referring to a root URL, e.g. https://example.com, not https://example.com/cool_stuff.  See Application Scan Targets, Scope, Seeded Targets and Denied Targets for more information.

Notifications

The scan Owner was set at the top of the page in

• Scan Settings
  • Belongs To

when you created the scan.  As well as changing this, you can also assign Watchers near the bottom of the page in

• Watcher Settings

The Owner and Watchers will receive email notifications when the scan starts and stops.

Scheduling

A scheduled start time for the scan, including a repeat, can be set in

• Scan Settings
  • Scheduled Start Date
  • Repeat

This is optional, the scan can be started manually, or via our API.

A scan window can also be set - running scans will automatically be paused outside of a scan window, if specified.  This can be found in

• Scan Window Settings
  • Add Schedule

Scanning Hub

By default scans are run from AppCheck's public Scanning Hubs.  If you have purchased a Private AppCheck Scanning Hub you will have the option of configuring which hub(s) your scan should run from.  This can be found at

• Advanced Config Settings
  • Scanning Hub

If you have not purchased a Private AppCheck Scanning Hub this option will not be shown.

Save

To finish creating your scan, click Save, or Save and Scan if you wish to also begin the scan immediately.

You will be able to edit the scan by selecting

• Scans
  • All Scans

then clicking the pencil icon:

Changes made to a scan configuration while the scan is running can be saved but will not take effect until the next time the scan starts.

Advanced Settings

Authentication

Configuring authentication for a web application scan is the most complex part of the scan setup, and so is discussed in a dedicated guide.

See also Managing Credentials for Scans

You may wish to familiarise yourself with basic scan creation by completing this guide before adding authentication; however, it is strongly recommended to set up an authenticated scan when you are ready.  If your application makes use of an authentication barrier then it is highly likely that much of the application will not be scannable without configuring authentication.

An authenticated scan should be in addition to an unauthenticated scan, not a replacement.  While it's more likely you will find vulnerablitiles behind your authentication barrier, vulnerabilities in font of, or in the authentication barrier may be higher impact, since the authentication barrier itself acts as a form of protection.

When you are ready to configure authentication, you will do so by assigning a set of Credentials to your scan, and usually a GoScript.

GoScripts and Credentials are managed in the GoScripts and Credentials sections of the interface and are linked, rather than copied, to your scan upon import.  Any subsequent changes made to your GoScript and/or Credentials will affect all linked scans the next time they run.

Basic Auth, Digest and NTLM have their own areas in the scan settings and GoScript testing interface.  If your application uses another non-UI based authentication process, or you have other specific needs, search our FAQs to find more guides, or raise a ticket with our support team if you cannot find the answers you're looking for.

Verifying Authentication Has Worked in Your Scan

Authentication has two parts: completing the authentication process itself, and analysing the results in order to replay authenticated requests.

In your scan's Info findings, you should see two Info level findings: Authentication Successful (or Unsuccessful) and Auth Analysis Successful (or Unsuccessful).  Success for both parts is necessary for a thorough authenticated scan.

If either part has failed, open the finding and select the Attachments tab.  Here you can see a log of the HTTP requests sent during the authentication process, details of which part has failed, and screenshots of what was seen in the browser at the time.  This can help to identify issues that only occur at scan time (for example your WAF may have blocked the IP address of the scan hub from which the scan is running, in which case you may see a block message in a screenshot).

Optimisations

Most scan settings should be left on the defaults, and this guide will not go in to any specific scan settings.  However, you may wish to peruse Making Scans Faster, starting with Platform-Specific Checks for Platforms You Do Not Use.

Further Reading

Integrations

See the following guides to integrate your scans with:

Microsoft Teams

Slack

Jira

CI/CD Pipelines