Skip to main content

IAST - Interactive (Runtime) Testing

Interactive Application Security Testing (IAST) is an in-process sensor that runs inside your application and watches request-derived (tainted) input reach a dangerous sink. When it does, IAST reports a runtime-confirmed finding - the strongest evidence tier in apPosture, an observed execution rather than an HTTP inference.

IAST does not replace DAST; it upgrades it. A DAST scan drives traffic from the outside while the IAST agent, inside the app, confirms exactly which inputs reached which sinks - turning "this response looks exploitable" into "this input executed at this sink."

Supported languages​

An in-process agent is available for four runtimes:

LanguageHow it attaches
PythonWSGI / ASGI middleware (Flask, Django, FastAPI)
Node.js--require preload hook
Java-javaagent (ByteBuddy bootstrap sensor)
.NETDOTNET_STARTUP_HOOKS (CoreCLR; C# / F# / VB)

What it detects​

Each sink family maps to a CWE and is reported the moment tainted input reaches it:

Sink familyCWE
SQL injectionCWE-89
Command injectionCWE-78
Code injectionCWE-94
Server-side template injectionCWE-1336
Path traversalCWE-22
SSRFCWE-918
XXECWE-611
NoSQL injectionCWE-943
DeserializationCWE-502
LDAP injectionCWE-90
JNDI / Log4ShellCWE-74
XPath injectionCWE-643
Unsafe reflectionCWE-470
XSSCWE-79

How it correlates with DAST​

During a scan the engine stamps every request it sends (crawler, active scanner, hybrid prober, Nuclei) with two headers: one carrying the scan id and one a per-request id. When the IAST agent sees a sink hit on an instrumented request, it ties that hit back to the driving scan and posts it to the backend. The confirmed finding is folded into that scan's posture and correlation like any other source, and it feeds the proof-first ranking on the Attack Chains - a runtime-proven hop outranks a merely-reachable one.

Off a scan the agent is inert: it observes only and no-ops when it sees no scan header.

Evidence & safety​

  • Confirmed IAST findings carry exploit_status = confirmed, exploit_technique = runtime-iast and verified = true.
  • The agent is observe-only: the original sink runs unchanged, agent errors are swallowed, and tainted values are masked on ingest per the evidence-privacy rule.
  • Value-presence matching uses a distinctive-token rule (not a plain substring) so an incidental match (user inside user_accounts) never produces a false positive.

Activation​

IAST is off by default and token-gated. The ingest endpoint returns 503 when no token is configured and 401 on a wrong token, so it cannot accept events until you deliberately enable it.

  1. Set the ingest token on the backend (IAST_AGENT_TOKEN).
  2. Deploy the matching agent alongside your target and point it at the backend with its per-agent environment variables:
    • APPOSTURE_IAST_URL - the runtime-events endpoint.
    • APPOSTURE_IAST_TOKEN - the same token as the backend.
    • APPOSTURE_IAST_SCAN_HEADER / APPOSTURE_IAST_REQUEST_HEADER - the correlation headers (defaults match the scanner).
    • APPOSTURE_IAST_MIN_TAINT - minimum tainted-value length to consider.

Because the agent must run inside the application process, IAST is used against instrumented test or staging deployments, not arbitrary external targets.

API​

  • POST /api/v1/runtime/events - ingest one event (public, gated by the X-IAST-Token header).
  • GET /api/v1/runtime/events - list ingested events (authenticated).
Last updated on