Detect application vulnerabilities with GitLab’s browser-based DAST

Proxy-based dynamic application security testing was removed in GitLab 17.0 (May 16, 2024) and replaced with GitLab's proprietary DAST tool (formerly called “browser-based DAST”). DAST runs automated penetration tests to find vulnerabilities in your web applications as they are running. DAST automates a hacker’s approach, simulates real-world attacks, and can identify critical threats such as cross-site scripting, a SQL injection, and cross-site request forgery. DAST is completely language-agnostic and examines your application from the outside in.

We recommend adding DAST to your software development security alongside other foundational application security testing such as secret detection, dependency scanning, static application security testing (SAST), container scanning, and API security testing. Including DAST in this defense-in-depth approach ensures that your team can identify and mitigate the runtime vulnerabilities and misconfigurations DAST detects that other security tools cannot detect. With a running application in a test environment, DAST scans can be automated in a CI/CD pipeline, automated on a schedule, or run independently by using on-demand scans. Read on to learn how to migrate to GitLab DAST, or how to get started if you aren’t already using this security feature.

Our decision to remove proxy-based DAST

Removal of support for proxy-based DAST in 17.0 was announced in 16.6. Proxy-based DAST was introduced in GitLab 10.4 (January 2018), and its foundation was the open source Zed Attack Proxy (ZAP) project. At the time, this provided great dynamic analysis within GitLab’s DevSecOps platform. Over time, however, the architecture of apps evolved and web applications grew in complexity. Legacy DAST crawlers, including proxy-based DAST, couldn’t provide sufficient coverage of modern applications so we began developing our modern, proprietary DAST solution. GitLab’s new DAST offering uses a browser to fully navigate the website like a real user while uncovering vulnerabilities. GitLab DAST runs on either arm64 or amd64 architectures, and a FIPS-compliant version is available as well. Our Vulnerability Research team wrote GitLab’s DAST detections and regularly updates our vulnerability definitions to ensure

DAST migration information

If you are using proxy-based DAST to run a scan in a CI/CD pipeline, we recommend migrating to DAST to continue dynamically scanning your web applications for vulnerabilities. Follow the configuration recommendations outlined in the DAST Migration Guide to ensure GitLab DAST scans can continue successfully.

If you would like to continue using proxy-based DAST, you can do so until GitLab 18.0 (May 2025). Bugs and vulnerabilities in this legacy analyzer will not be fixed. To continue using the non-supported proxy-based DAST, set the CI/CD variable <DAST_VERSION:4> .

If you are using on-demand DAST scans, they automatically began using the newer DAST analyzer (effective from the third GitLab 17.0 breaking change window, 2024-05-06 09:00 UTC to 2024-05-08 22:00 UTC), without any required action on your part.

Migrate to GitLab DAST

If you aren’t using DAST yet, you can either run automatic DAST scans that are initiated by a merge request, or you can run manual on-demand DAST scans.

To enable automated scans, follow these simple getting started steps:

1. Edit your .gitlab.ci.yml file to include the DAST template <DAST.gitlab-ci.yml>
2. Add a DAST stage to the CI/CD pipeline definition. This should be added after the deploy step.
3. Define the URL to be scanned by DAST by using one of these methods: Set the <DAST_TARGET_URL> variable. If set, this value takes precedence Add the URL in a <environment_url.txt> file at your project’s root
4. Configure authentication to ensure DAST can crawl as much of your application as possible.

A basic configuration for an application with a single-step login form might look like this:

include:
  - template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_TARGET_URL: "https://example.com"
    DAST_AUTH_URL: "https://example.com/login"
    DAST_AUTH_USERNAME_FIELD: "css:[name=username]"
    DAST_AUTH_PASSWORD_FIELD: "css:[name=password]"
    DAST_AUTH_SUBMIT_FIELD: "css:button[type=submit]"

To run DAST scans manually outside of the DevOps lifecycle, follow these steps to create an on-demand scan.

How DAST works

Once a DAST scan has been triggered, the following steps occur:

1. Authenticate - If you have configured authentication, the analyzer will authenticate to allow maximum crawling coverage. If authentication fails, the scan halts.
2. Discovery - The crawler discovers the surface area of the target application by performing user actions like following links, clicking buttons, and filling out forms.
3. Passive checks - Identifies vulnerabilities in HTTP messages and pages discovered while crawling. These are enabled by default.
4. Active checks - Identifies vulnerabilities by injecting payloads into HTTP requests recorded during the crawl phase. DAST:

• analyzes HTTP requests for injection locations (including but not limited to query values, header values, cookie values, form posts, JSON string values, and XML entities)
• injects attack payloads into those locations and analyzes the HTTP responses to determine attack success and report vulnerabilities

Active checks are disabled by default due to the nature of their probing attacks. Scan results should be reviewed via the Vulnerability Report to prioritize and remediate the detected vulnerabilities.

DAST benefits

Here are some of the benefits of incorporating DAST into your software development lifecycle:

• simulates real-world hacking on running applications (pre-production versions recommended only)
• produces high-confidence, low false-positive findings
• identifies 9/10 of the OWASP Top 10:2021 (dependency scanning covers the 10th)
• detects CWEs and provides developers and security teams with remediation guidance before your code goes into production
• does not analyze source code, so scans are not limited by programming language or framework
• has a FIPS Compliant analyzer available, ensuring data is protected at rest and at transit according to the Federal Information Processing Standard supports complex, multi-step sign-in workflows
• utilizes a headless browser to provide excellent crawling coverage and execute all client-side scripting interactions for modern web applications, including SPAs

Get started today

GitLab DAST is an essential tool to include in your comprehensive security testing program. Our latest crawler provides excellent security coverage of modern applications, whether they are stateless or stateful single-page web apps). Use DAST in conjunction with GitLab’s other security analyzers to remain compliant with numerous standards, reduce business risk, and detect and remediate cyber threats prior to releasing them into production.

Sign up for a free 30-day trial of GitLab Ultimate to get going with GitLab DAST.

Additional resources

• DAST Migration Guide
• Tips to configure browser-based DAST scans
• Introducing browser-based DAST and integrated passive checks
• Introducing GitLab browser-based active checks in DAST