skip to content

Which OWASP ZAP add-ons will the program refuse to start without, and how is that enforced?

level: middleimportance: nice to knowfreq 28%

answer

  1. exactly two, and the list is a literal
  2. missing one and startup throws
  3. uninstall refused over API and CLI
  4. their extensions cannot be disabled
  5. one carries the proxy, one the update route

basics

~20 s

ZAP hard-codes two mandatory add-ons, callhome and network, in core's ControlOverrides. If either is missing the add-on collection throws at startup, and once marked mandatory neither can be uninstalled, blocked, or have its extensions disabled.

solid answer

~40 s

Core's `ControlOverrides.getMandatoryAddOns()` returns a hard-coded pair — `callhome` and `network` — and it is not a configuration key. `AddOnCollection.setMandatoryAddOns` throws an `IllegalStateException` naming the missing id if either is absent, so the program stops rather than degrading. Once an add-on is flagged mandatory, the control API's uninstall action rejects it as an illegal parameter, the `-addonuninstall` argument refuses it, `ExtensionFactory` force-enables its extensions regardless of the per-extension enabled setting, and the loader never adds it to the block list. The two are load-bearing for different reasons: `network` carries the local proxy listener and the root certificate authority, and `callhome` is the only route to the marketplace, because core's auto-update extension reaches it through a supplier that only `callhome` installs.

code

bash · 10 lines
bash
# A mandatory add-on cannot be removed, over the CLI or over the control API.
zap.sh -cmd -addonuninstall network
# -> refused; 'network' is mandatory, so nothing is removed

# What a locked-down pipeline does instead: suppress unsolicited outbound calls.
zap.sh -cmd -silent -addonlist

# -silent is not an offline switch: an explicit update is still a deliberate
# request, which is why the project's own image builds pair the two.
zap.sh -cmd -silent -addonupdate

go deeper

for a junior

Remember that two ZAP add-ons are mandatory and that one of them supplies the local proxy. The useful takeaway is that the proxy is not core code, and that ZAP will not start if its archive is missing.

for a middle

Name both add-ons, say the list is hard-coded in core rather than configurable, and describe at least two of the enforcement paths — the startup failure, the uninstall refusal, or the forced enabling of their extensions.

for a senior

Turn it into an operational answer. When a network team asks you to remove the component that makes outbound calls, explain that it is mandatory, that the supported lever is a core argument that suppresses unsolicited requests, and that egress control is the independent backstop.

for a principal

Recognise what this says about the product's shape: the program's own update path is an add-on. Any policy that treats add-ons as removable extras will eventually collide with the fact that two of them are the program.

## The list, and where it lives ZAP treats two add-ons as mandatory: **`callhome`** and **`network`**. The list is returned by `ControlOverrides.getMandatoryAddOns()` in core and it is a literal in the source — not an option, not a config key, not something a deployment can shorten. At startup `Control` passes it to `AddOnCollection.setMandatoryAddOns`, which looks each id up and, if one is absent, logs and throws an `IllegalStateException` naming the missing add-on and pointing at the developer documentation. The program does not degrade; it stops. ## What "mandatory" buys, mechanically Marking an add-on mandatory is not advisory. Four separate paths check the flag: 1. **Uninstall over the control API** — the auto-update API's uninstall action rejects a mandatory id as an illegal parameter before it does anything. 2. **Uninstall from the command line** — the `-addonuninstall` path logs an error for a mandatory id and moves on to the next one. 3. **Disabling its extensions** — `ExtensionFactory` computes `mandatory || isExtensionEnabled(name)`, so a mandatory add-on's extensions are enabled whatever the per-extension setting says. The desktop's extension table also refuses to make those rows editable. 4. **The block list** — when a file cannot be deleted, the loader normally records the id in a block list so it is skipped next time. For a mandatory add-on it returns without recording anything. ## Why these two, specifically | add-on | what the program loses without it | |---|---| | `network` | the local proxy listener and the root certificate authority — the path every intercepted request travels | | `callhome` | every outbound call the program makes on its own behalf, **including the marketplace lookup** | The second one is less obvious and more interesting. Core ships the whole marketplace surface — the install, uninstall, update and list arguments, the dialogs, the API component — but it does not ship the network trip. `ExtensionAutoUpdate` reads the remote catalogue through a supplier that something else has to set, and returns `null` when nothing has. The add-on that sets it is `callhome`. So **core carries the marketplace user interface and an add-on carries its only route out**, which is a compact illustration of how thoroughly capability has been pushed out of the program. ## What a locked-down pipeline can actually do The usual request — *"remove the component that phones home"* — has no answer, because that component is mandatory. The available levers are different: - Core's `-silent` argument sets a flag (`Constant.isSilent()`) that means *make no unsolicited requests*. The add-on checks it before sending, and the project's own image builds pass it. - The telemetry behaviour also has its own enabled option, checked alongside the silent flag. - Egress control at the network layer remains available and is the only lever that does not depend on the program behaving as documented. - The add-on listing is a read-only argument and makes no outbound call, so auditing an image's set does not itself need egress. And two things that are **not** levers, because people reach for them first: - deleting the archive from the plugin directory, which leaves the collection unable to find a mandatory id and stops startup; - disabling the add-on's extensions in the options, which the forced-enable rule overrides. Note what `-silent` does **not** do: it suppresses unsolicited calls, so an explicit `-addonupdate` or `-addoninstall` on the same command line is still a deliberate request and still needs the marketplace. That is why the project's own image builds pair `-silent` with `-addonupdate` — one suppresses the chatter, the other is the trip they meant to make. ## Status is not importance, and this is the proof Of the two mandatory add-ons, one ships at **release** and the other at **beta**. If a status label were a fitness or importance signal, the add-on the program refuses to start without would not be the one below release. It is the clearest available evidence that the two axes are independent. ## The sentence to keep *Two add-ons are mandatory and the list is hard-coded: `callhome` and `network`.* If you need to justify an egress exception, the honest framing is that ZAP's proxy and its update path are add-ons the program will not run without, and that the supported way to quieten one of them is a core argument rather than a removal.

  • Why is `callhome` mandatory when its job sounds optional?
    Because it owns the only route to the marketplace. Core ships the install, update, uninstall and list arguments and the update dialogs, but reads the remote catalogue through a supplier that must be set by something else; with no supplier the remote configuration is simply `null`. The `callhome` add-on is what sets it, so removing it would leave core's whole marketplace surface inert.
  • Can a deployment shorten the mandatory list?
    No. It is a literal returned by core's `ControlOverrides`, not a configuration key, and the collection throws an `IllegalStateException` naming the missing id if either add-on is absent. Any change to the pair is a change to the core program, which is a different decision from composing an add-on set.

saying these in an interview costs you the question

  • Says any add-on can be uninstalled if you have API access.
  • Assumes a mandatory add-on must therefore be at release status.
  • Thinks the mandatory list is a configuration key a deployment can edit.
  • Believes disabling a mandatory add-on's extensions in options works.
  • Treats `-silent` as a full offline switch rather than a no-unsolicited-calls flag.