Yes, some can. A blind vulnerability gives no visible sign in the HTTP response, so a normal scan misses it. Out-of-band testing works around this by planting a payload that makes the app contact a server the tester controls, and the callback is the proof.
What "blind" means
In most web attacks the tester reads the response to see whether the payload worked. A blind flaw hides that signal. The server may run a query, fetch a URL or process a template, yet return an ordinary page. Examples include server-side request forgery, some injection flaws that run in background jobs, and bugs triggered when an admin later opens a record.
What "out-of-band" means
Out-of-band means the evidence arrives on a different channel than the response. The scanner sends a request containing a unique address that points to an external listener. If the application resolves that address or requests it, the listener records the hit. Because each payload carries a unique tag, the scanner can match the callback to the exact request that caused it.
The ZAP OAST add-on documentation describes this as letting you detect and exploit out-of-band vulnerabilities in web applications. It also notes that scan rules using it may produce alerts that are not seen immediately, or are not attributed to a specific active scan, since the callback can happen out of band and potentially at a later time.
What that delay means for you
| Situation | What to do |
|---|---|
| Alert appears after the scan ended | Keep the listener and the session open long enough to catch late callbacks |
| Alert has no clear source request | Use the payload tag to find the original request in your logs |
| No callbacks at all | Check egress rules, they may be blocking the app from reaching the listener |
That last row matters. Many production networks block outbound traffic. If the app cannot call out, an out-of-band test returns nothing, and a quiet result may reflect the network, not safety.
Steps to run an out-of-band test
- Confirm you can receive callbacks. Use a listener reachable from the test environment, either a hosted one or one you run.
- Check egress. Decide whether the test app may call that listener. If policy says no, plan a different approach.
- Enable the rules. Turn on out-of-band rules in your scan policy and give the scanner the listener address.
- Run the scan and keep waiting. Do not tear down the listener when the crawl finishes. Allow a grace period.
- Match and verify. For each callback, find the originating request, reproduce it by hand and confirm the cause.
- Fix and retest. Often the fix is an allowlist for outbound requests or safer parsing.
Privacy and policy points
Using an external listener means data from your test app, such as request details, may leave your network. Use test data only, and check your policy before sending payloads to a hosted service. Self-hosting the listener keeps traffic inside your boundary.
Limits
Out-of-band testing does not cover everything. It catches flaws that cause an outbound call, not every kind of blind bug. A time-based or error-based check may be needed for others. It also needs a real target path: a scanner can only plant payloads in inputs it found.
A worked example
A team runs an invoice service that fetches a logo from a URL a customer supplies. The page returns the same "Saved" message whatever the URL. A normal scan sees nothing wrong.
With out-of-band testing on, the scanner submits the form with a unique address in the logo field, such as a random tag on a listener domain. A short time later the listener logs a request from the invoice service's network address, with the same tag. That callback proves the service fetches attacker-chosen URLs, which is the pattern behind server-side request forgery.
The team follows a clear sequence.
- Confirm the finding. They submit the same request by hand with their own listener address and see the callback again.
- Measure the reach. They try an internal address in a test environment to see whether the service can reach private systems. They use test systems only.
- Choose a fix. They restrict the fetcher to an allowlist of approved hosts, block private address ranges, and set short timeouts.
- Retest. They resubmit the payload and confirm no callback arrives.
- Keep a regression test. They add the case to their test suite.
Where blind bugs hide
| Feature | Why it can be blind |
|---|---|
| Link previews and URL importers | Server fetches the URL and shows a generic result |
| Webhook and callback settings | Requests go out later, from a queue |
| PDF and image generators | Rendering engine loads remote resources silently |
| Email and notification templates | Input is processed when a message is sent |
| Admin review screens | Payload fires when staff open a record |
| Log and analytics pipelines | Input is processed in a separate system |
Time matters
Some callbacks arrive minutes or days after the request. If a scan finishes and the listener is shut down, those callbacks are lost. Keep the listener running for a defined grace period, and review its log again later. Note in the record that late callbacks may still appear.
Decide who runs the listener
| Option | Benefit | Concern |
|---|---|---|
| Hosted by a third party | Quick to start | Test traffic details leave your network |
| Run by you, outside your network | Control over logs | You must maintain it and secure it |
| Run by you, inside a lab network | Data stays inside | The app must be allowed to reach it |
Pick the option that matches your data rules. Use test data in every case.
What a quiet result means
No callbacks does not prove the app is safe. It may mean outbound traffic is blocked, the payloads never reached the right inputs, or the processing happens in a system you did not test. Say so plainly in the report, and record the egress rules you observed.
Where Safeguard fits
This is a category explainer on web testing. Safeguard's own focus is the software you ship, including SBOM and dependency scanning with reachability analysis. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch one scan from crawl to results and relate it to the steps above.
Quick check
Why did my out-of-band scan find nothing?
The app may be blocked from calling out, or the callback may arrive after you stopped listening.
Is an out-of-band callback proof of a vulnerability?
It is strong evidence. Reproduce it by hand to confirm the cause before filing a fix.
Which features should I test first for blind issues?
Start with anything that fetches a URL, sends a webhook, renders a document or processes input later, such as admin review screens and notification templates.
Sources
Last reviewed: 19 October 2026.
