The host of API specification can be overridden when specification is a file

Problem to solve

Specifications of an API are passed to DAST using the DAST_API_SPECIFICATION environment variable. The value passed is either:

• the name of a file that is contained in the /zap/wrk directory on the docker container
• the URL of location that hosts the specification

Specifications often contain host names that do not match the test environment where the API is hosted. For example, with a OpenAPI V3 specification containing:

servers:
  - url: https://api.host.com

If the test version of the API is running at https://api-test.host.com, and the specification is hosted on a URL http://api-test.api.com/api-specification.yml, then the following DAST configuration can be used:

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

variables:
  DAST_API_SPECIFICATION: http://api-test.api.com/api-specification.yml
  DAST_API_HOST_OVERRIDE: api-test.api.com

If the specification is contained in a file e.g. api-specification.yml, then the DAST_API_HOST_OVERRIDE should work as it does with a URL:

dast:
  script:
    - mkdir -p /zap/wrk
    - cp api-specification.yml /zap/wrk/api-specification.yml
    - /analyze -t $DAST_WEBSITE
  variables:
    GIT_STRATEGY: fetch
    DAST_API_SPECIFICATION: api-specification.yml
    DAST_API_HOST_OVERRIDE: api-test.api.com

Unfortunately, in the above example the host name does not get overridden and the DAST scan fails.

Intended users

• Sasha (Software Developer)
• Sam (Security Analyst)

Proposal

DAST_API_HOST_OVERRIDE should work whether DAST_API_SPECIFICATION is a URL or a file.

External dependency

This is likely a limitation with ZAP, and will require changes to be made upstream.

Documentation

Documentation should be updated to communicate that this feature is now supported.

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Gold/Ultimate

/cc @sethgitlab @derekferguson