I don't understand what you mean, can you elaborate.

ZAP 2.5.X requires a starting point URL to be provided, this is from where the scan will originate as described in the documentation and the help tip in the plugin itself. It is not possible to leave this field empty. Similarly i am not sure how you would set this up in the UI either since it's not an available functionality.

You can include regex already into the context for each specific build.

But i also don't understand why this should be in the administration interface as a global setting rather than on a per job basis and specific to each application under test.

Yes, I'll elaborate and try to explain my needs.
Say I work for E. Corp. For internal usage, developers have access to a Jenkins with the zap-plugin so that they can test their applications during development.
This being a corporate tool, users should only be allowed to create a scan against *.e-corp.biz and not the full open web

Let me see if i understand correctly. I have my domain, let's call it mysite.com

and i have three applications under it.

• mysite.com/appA/
• mysite.com/appB/
• mysite.com/appC/

In this case, the app under test will be mysite.com/appA/ and it will be the Target URL. You want a list in admin configurations that will allow you to restrict the target URL so that if they enter an invalid domain such as mikesite.com/appA/ it will fail or return an invalid URL error?

Is that correct? In which case, is there really a need this functionality since it's internal usage and provides the same functionality as the UI. Your developers should not be adding external sites to the context either but the tool itself does allow them.

Yes that's it, a filter on the starting URL so that only approved URL can be entered. Filter to be defined in the admin section.
In an ideal world, this should not be needed in a company, but then in an ideal, ZAP should not be needed at all ^^'

Regarding the implementation, either a direct validation of the parameter or a failure to build will do it. Even if I think it will be a better UX for the user if the field itself doesn't allow unauthorized input rather than find out later that the build has failed.