skip to content

In ZAP, what is a `targeted` script, and what has to happen before one runs?

level: juniorimportance: should knowfreq 28%

answer

  1. pull, not push
  2. one method, one message
  3. nothing hands it traffic
  4. invokeWith, and no helper argument
  5. the run action is standalone-only

basics

~10 s

A targeted script implements one method, invokeWith, handed a single HTTP message. It never fires on traffic: something must choose a message and invoke the script with it.

solid answer

~40 s

The `targeted` type is the simplest contract of the script types: one function, `invokeWith(msg)`, taking one message. There is no initiator argument and no send helper, because there is no traffic flowing past it — the script is invoked on a message somebody already chose. That makes it the one hook of the message-handling types that is **pull** rather than **push**: the other types are called as messages go by, while this one waits to be pointed at something. The shipped community examples say so in their own header comments. The control surface will not start one either: its only run action is restricted to standalone scripts and rejects any other type by name.

code

javascript · 4 lines
javascript
function invokeWith(msg) {
  print(msg.getRequestHeader().getURI().toString());
  print(msg.getResponseHeader().getStatusCode());
}

go deeper

for a junior

Hold on to the shape: one function taking one message, and nothing runs it by itself. If you want code that reacts to traffic, this is not the type.

for a middle

Explain why the signature has no initiator and no helper, and name what actually invokes one. Be able to say which hook you would move the work to if it had to happen for every request.

for a senior

Recognise this as the type that does not transfer from a desktop workflow into an unattended run, and say why: nothing in the control surface starts one, and no listener is registered for it.

for a principal

The call to own is which of these seams a team may build on at all. A hook that only a person can trigger is fine as an investigation aid and a poor foundation for anything a pipeline is expected to repeat.

## The contract A **`targeted` script** implements a single method. In a script that is one top-level function: ```javascript function invokeWith(msg) { // do something with this one message } ``` That is the whole interface. Compare it with the other message-handling types and the omissions are the point: | | what it receives | when it fires | |---|---|---| | `httpsender` | the message, an initiator, a send helper | for every message the program sends | | `proxy` | the message | for every message crossing the local proxy listener | | `targeted` | the message, and nothing else | only when something invokes it with a chosen message | There is no initiator because nothing caused this message to be sent right now — it is a message that already exists. There is no helper because the type is not built around participating in a flow. ## Push versus pull The other two types are **pushed** work: the program is sending traffic and calls your code as it goes. A targeted script is **pulled**: it does nothing until something hands it a message. The shipped community examples state this in their own opening comments, which is a fair sign of how often it is misunderstood. On the desktop that something is you, choosing a recorded message and invoking the script on it. The natural uses follow from the shape: turn one request into a copied command line, extract something from one response, build a proof-of-concept from a single recorded exchange. They are all things you do to one message you have already looked at. ## What cannot start one Two limits are worth stating because both come up when someone tries to move a working desktop script into an unattended run: - **The control surface will not run one.** The scripting component's only run action is for standalone scripts, and it checks the type by name and refuses anything else. There is no equivalent action for a targeted script. - **Traffic will not trigger one.** No listener is registered for this type. A targeted script that is loaded and sitting there does nothing at all while a scan runs past it. So the type's answer to "how do I run this every time?" is that you do not; you choose a different hook. Work that must happen for each message belongs on the sending hook, and work that must happen once belongs in a standalone script. ## One consequence of not being enableable Script types declare whether their scripts can be enabled and disabled. This one does not, and that has a quiet side effect on failure handling. When a script raises an exception the program records the error and then disables it — but the disable step is skipped for types that cannot be disabled. So a targeted script that throws fails **only for that invocation**: fix it, invoke it again, and it runs. A sending hook that throws is taken out of service for the rest of the run. Two types, two very different consequences for the same mistake. ## Choosing between the three 1. **Does it need to see traffic as it happens?** Use the sending hook, and expect to branch on the initiator. 2. **Does it need to be able to stop traffic?** Only the proxy hook can do that, and only for traffic crossing the local listener. 3. **Is it something you do to one message you picked?** That is this type, and it is the right answer far less often in a pipeline than on a desktop — which is worth saying out loud, because many of the showiest community examples are of exactly this kind. ## What this costs you in an unattended run The practical consequences are all the same consequence seen from different sides: - A targeted script that is loaded and sitting in an unattended run is **inert**, and nothing reports that. - Porting a desktop workflow that ends in "then run this script on the interesting request" means finding the interesting request some other way first. - Work that must happen for every message has to move to the sending hook, where the signature changes: you gain an initiator and a helper, and you lose the guarantee that a human chose this message. ## Where the type comes from Like the other two message-handling types, `targeted` is registered by the **`scripts` add-on**, not by the core program. Core declares the interface and marks it deprecated for removal. So the whole family — the type, the contract and the language to write it in — is add-on territory, which is the thing to check first when a script type you expected is simply not in the list.

  • Why does a targeted script get no initiator argument?
    Because nothing is sending the message at that moment. The initiator exists on the sending hook to say which part of the program produced the traffic flowing past; a targeted script is handed a message that already exists, chosen by someone else.
  • Can the control surface be used to run a targeted script on a message?
    No. The scripting component's only run action is for standalone scripts and it checks the type by name, refusing anything else. There is no equivalent action for this type.
  • A targeted script and a sending hook both throw. Why does only one of them stop working?
    Because the disable step applies only to script types that can be enabled and disabled. The sending hook is one of those, so it is switched off. The targeted type is not, so the error is recorded for that invocation and the script still runs the next time it is invoked.

saying these in an interview costs you the question

  • Thinks a targeted script fires automatically on matching traffic
  • Expects an initiator or a send helper in its signature
  • Says the control surface can run one on a chosen message
  • Assumes it is registered by the core program
  • Believes an exception disables it as it would a sending hook