doc/user/application_security/dast/browser/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
[!warning] The DAST version 4 browser-based analyzer is replaced by DAST version 5 in GitLab 17.0. For instructions on how to migrate to DAST version 5, see the migration guide.
Browser-based DAST helps you identify security weaknesses (CWEs) in your web applications. After you deploy your web application, it becomes exposed to new types of attacks, many of which cannot be detected prior to deployment. For example, misconfigurations of your application server or incorrect assumptions about security controls may not be visible from the source code, but they can be detected with browser-based DAST.
Dynamic application security testing (DAST) examines applications for vulnerabilities like these in deployed environments.
<i class="fa-youtube-play" aria-hidden="true"></i> For an overview, see DAST - advanced security testing.
[!warning] Do not run DAST scans against a production server. Not only can it perform any function that a user can, such as clicking buttons or submitting forms, but it may also trigger bugs, leading to modification or loss of production data. Only run DAST scans against a test server.
The DAST browser-based analyzer was built by GitLab to scan modern-day web applications for vulnerabilities. Scans run in a browser to optimize testing applications heavily dependent on JavaScript, such as single-page applications. See how DAST scans an application for more information.
To add the analyzer to your CI/CD pipeline, see enabling the analyzer.
If you're new to DAST, follow this guide to set up your first scan.
Prerequisites:
docker executor on Linux/amd64.To get started with DAST:
After completing your first scan:
You can review vulnerabilities in a pipeline:
You can also download the security scan results:
For more details, see Pipeline security report.
[!note] Findings are generated on feature branches. When they are merged into the default branch, they become vulnerabilities. This distinction is important when evaluating your security posture.
For information about configuring DAST for a specific application or environment, see the configuration options.
After you configure DAST for a single project, you can extend the configuration to other projects:
Take care if your pipeline is configured to deploy to the same web server in each run. Running a DAST scan while a server is being updated leads to inaccurate and non-deterministic results.
Configure runners to use the always pull policy to run the latest versions of the analyzers.
By default, DAST downloads all artifacts defined by previous jobs in the pipeline. If
your DAST job does not rely on environment_url.txt to define the URL under test or any other files created
in previous jobs, you shouldn't download artifacts. To avoid downloading
artifacts, extend the analyzer CI/CD job to specify no dependencies. For example, for the DAST proxy-based analyzer add the following to your .gitlab-ci.yml file:
dast:
dependencies: []
A scan performs the following steps:
A "navigation" is an action a user might take on a page, such as clicking buttons, clicking anchor links, opening menu items, or filling out forms. A "navigation path" is a sequence of navigation actions representing how a user might traverse an application. DAST discovers the surface area of an application by crawling pages and content and identifying navigation paths.
Crawling is initialized with a navigation path containing one navigation that loads the target application URL in a specially-instrumented Chromium browser. DAST then crawls navigation paths until all have been crawled.
To crawl a navigation path, DAST opens a browser window and instructs it to perform all the navigation actions in the navigation path. When the browser has finished loading the result of the final action, DAST inspects the page for actions a user might take, creates a new navigation for each found, and adds them to the navigation path to form new navigation paths. For example:
LoadURL[https://example.com].LeftClick[class=menu] and LeftClick[id=users].LoadURL[https://example.com] -> LeftClick[class=menu] and LoadURL[https://example.com] -> LeftClick[id=users].It's common for an HTML element to exist in multiple places in an application, such as a menu visible on every page. Duplicate elements can cause crawlers to crawl the same pages again or become stuck in a loop. DAST uses an element uniqueness calculation based on HTML attributes to discard new navigation actions it has previously crawled.
Passive scans check for vulnerabilities in the pages discovered during the crawl phase of the scan. Passive scans attempt to interact with a site in the same way as a normal user, including by performing destructive actions like deleting data. However, passive scans do not simulate adversarial behavior. Passive scans are enabled by default.
The checks search HTTP messages, cookies, storage events, console events, and DOM for vulnerabilities. Examples of passive checks include searching for exposed credit cards, exposed secret tokens, missing content security policies, and redirection to untrusted locations.
See checks for more information about individual checks.
Active scans check for vulnerabilities by injecting attack payloads into HTTP requests recorded during the crawl phase of the scan. Active scans are disabled by default because they simulate adversarial behavior.
DAST analyzes each recorded HTTP request for injection locations, such as query values, header values, cookie values, form posts, and JSON string values. Attack payloads are injected into the injection location, forming a new request. DAST sends the request to the target application and uses the HTTP response to determine attack success.
Active scans run two types of active check:
A simplified timing attack works as follows:
https://example.com?search=people.https://example.com?search=[INJECT].sleep 10, that attempts to get a Linux host to sleep.https://example.com?search=sleep%2010.system(params[:search])