What it means
DAST interacts with a running application and evaluates its observable responses. It can reveal behavior that depends on routing, configuration, authentication, or how components fit together. Because it works through an interface, it may lack the code context needed to explain the root cause. It also sees only the functionality its test accounts and requests can reach. A scanner that cannot log in may report a reassuring result after examining little more than the login page. Testing scope and coverage are therefore part of the result.
The idea at a glance / Software
Compare a normal request with a changed input.
DAST observes responses from a running test application; the controlled comparison changes one input and preserves the build and test scope.
SearchDesk is an authorized, isolated fictional test build C51 with only the synthetic names Lee and Sam. Both requests use GET /search with the same build, public test access, and unchanged dataset. Only the name query parameter changes. These are fixed teaching records.
READ THE PICTURE
Compare the evidence
Request A searches for Sam and gets ["Sam"]. Request B changes only name to x' OR '1'='1 and gets ["Lee","Sam"]. The changed response supports a SQL-injection investigation. These responses do not explain the internal cause or prove that other inputs were tested.
Keep in mindResponses alone do not identify the internal code or establish coverage of other routes, roles, or deployments. The SAST example supplies separate code evidence. No customer data, mutation, completed repair, or production deployment is shown.
Read the complete example
- Compare the evidence. Request A searches for Sam and gets ["Sam"]. Request B changes only name to x' OR '1'='1 and gets ["Lee","Sam"]. The changed response supports a SQL-injection investigation. These responses do not explain the internal cause or prove that other inputs were tested. Both results are HTTP 200 responses to GET /search. A sends name=Sam; B sends the decoded name value x' OR '1'='1. The fixture orders names alphabetically, so the probe response is ["Lee","Sam"]. Its unsafe query construction is known from separate source review, not revealed by these responses alone. Follow-up work should preserve the evidence, confirm the cause, and verify a parameterized-query correction with both an ordinary search and a probe. No such correction is applied to the C51 build shown here. The isolated fixture origin is https://search.example.test. The diagram displays decoded name values; an actual URL encodes them. These records are checked locally rather than collected from a live scanner.
Responses alone do not identify the internal code or establish coverage of other routes, roles, or deployments. The SAST example supplies separate code evidence. No customer data, mutation, completed repair, or production deployment is shown.
Diagram references: OWASP: Testing for SQL Injection (WSTG 4.2) · OWASP: SQL Injection Prevention
AN ILLUSTRATIVE SCENARIO
Two requests to one unchanged build
An authorized test uses isolated SearchDesk build C51 and only synthetic names Lee and Sam. GET /search with name=Sam returns ["Sam"]. Changing only name to x' OR '1'='1 returns ["Lee","Sam"], both with HTTP 200. That difference supports investigating SQL injection. Source review supplies the cause separately; the response is not an explanation of internal code. C51 is still unchanged. After correcting the query, check that ordinary searches still work and that the probe is treated as a literal name.
Put it to work
- Agree the authorized hosts, roles, time window, test intensity, and excluded actions. Use an isolated environment, synthetic data, and disabled or simulated external side effects.
- Provide representative authenticated workflows and monitor application health during testing. Record which pages, interfaces, roles, and paths the test reached, including failed authentication or blocked routes.
- Validate findings, identify the server-side cause, and retest the correction with both allowed and disallowed requests. Retain enough request and response detail for developers without storing unnecessary sensitive data.
How to check your work
Confirm the test reached its intended route, role, and build. Preserve an ordinary baseline and the probe response. After a correction, repeat both: a parameterized exact-name query should still find Sam and treat the probe as data, returning no match in this fixture. Review untested coverage separately.
Connect the ideas
- SAST
Analysis of source or bytecode for vulnerability patterns without running the program.
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
- Coverage
An explicit statement of which sources, time windows, and rows were actually collected, including truncation.