7 security gaps DAST can uncover in running applications

Once an application is live, its behavior is shaped by more than the code base that developers have reviewed. Authentication may now depend on an external identity provider, while API routes can expose functionality the main interface never shows. Those runtime details can change which weaknesses are reachable, and some categories of risk barely touch the codebase at all. Security misconfiguration is a clear example. Default credentials left unchanged, verbose error handling, and publicly exposed cloud storage are introduced by deployment and environment settings, not by application code, which means code review and static analysis have little chance of catching them. That may be one reason the category has climbed so fast in OWASP's data. Across more than 2.8 million applications, 'Security Misconfiguration' rose to second place among the most commonly found risks last year, up from fifth in 2021, with more than 719,000 occurrences recorded. Stay Ahead of the Curve! Don't miss out on the latest insights, trends, and analysis in the world of data, technology, and startups. Subscribe to our newsletter and get exclusive content delivered straight to your inbox. Subscribe Now Catching these types of issues requires testing the application as it actually runs. A request may cross an access boundary that looked sound in development, or it might reach a route nobody expected to be public. The seven gaps below show where that runtime view becomes useful. 1. Authentication paths that behave differently at runtime Using DAST on a running application lets teams probe authentication paths exposed by the deployed system. A scanner can move through login and password-reset flows while observing how the application responds. This can reveal alternate paths with weaker controls, such as a protected page that still responds to a direct request. Changes to password reset or single sign-on can also leave behind routes that no longer follow the intended authentication model. The login screen can become a hard limit for an unauthenticated scan. Representative test accounts let the scanner reach the parts of the application that real users see after signing in. 2. Session controls across user states Session security unfolds over a series of requests. Its state changes after login and again when the user leaves or times out. The application has to maintain that state consistently as the user moves through the system. Logout should invalidate the session, while sensitive transitions may require a fresh identifier. Timeout behavior adds another point for testing. Following the full sequence enables the test to compare session behavior before and after authentication. It can also reveal whether an old session remains usable or whether cookie settings weaken the intended controls. These weaknesses often appear in the sequence itself, which makes the application's state changes important evidence during testing. 3. Authorization gaps between users and resources Authentication establishes the user's identity. Authorization then governs what that account can reach or change. The challenge grows when one application serves several account types or exposes records through APIs. Changing an object ID or request parameter can reveal whether the application consistently enforces those boundaries. Broken Access Control remains first in OWASP's rankings. Its examples include manipulating object identifiers and API requests to get around intended restrictions. Changing an identifier while switching between test accounts shows whether the same resource is protected consistently. The responses make any mismatch easier to spot. Business-specific permissions can still demand manual testing. A scanner has little way to infer why one employee should approve an action while another should merely view it. 4. Input handling that becomes exploitable Modern applications take input from far more than forms. Data arrives through API payloads and request parameters. Cookies and headers can influence application behavior as well. Dynamic scanners can send crafted values through these interfaces and watch what comes back. This is where familiar flaws such as cross-site scripting (XSS) and SQL injection can surface. The CWE Top 25 still ranks XSS first and SQL injection second, based on 39,080 CVE records. A runtime finding can give developers a reproducible request and endpoint. That evidence helps connect the weakness to behavior they can inspect in the deployed application. Some inputs remain difficult to reach automatically. They may appear late in a workflow or depend on a particular account state. Scanners need enough workflow context to reach them. 5. Deployment misconfigurations exposed at runtime Deployment introduces settings that may never appear in the application repository. Debug settings and error handling can change what a remote user sees. Server and proxy configuration can also change what is reachable. Once those settings are active, ordinary requests can reveal problems introduced during deployment. A production-like staging environment can expose these differences before release while keeping testing away from live users. Production scanning is possible, but the test profile needs tighter controls. Some checks can alter data or put unnecessary load on live endpoints. 6. APIs and endpoints users never see Clicking through a web application yields an incomplete map of what it exposes. A mobile client may use a separate API while front-end code calls other endpoints in the background. Partner integrations can expose functions absent from the browser interface. Old routes may remain reachable long after the interface that used them is gone. A scan can exercise known API operations directly. An API specification provides a map of available routes and accepted inputs. Recorded traffic can help reveal workflows that ordinary crawling may miss. Teams also need to know which endpoints the scanner never reached. If important authenticated routes are missing from the scan, the result says little about them. 7. Weaknesses at the seams between systems Some weaknesses emerge from the way separate systems interact. An access rule may hold in the main interface but fail through an API route. Proxies can alter request handling, while an external identity service may introduce a path developers did not account for. Error and redirect behavior can change with configuration as well. Once the systems are connected, those interactions become visible from the outside. Automated crawling can miss workflows that depend on unusual sequences or business context. Black-box results show the exposed behavior. Source-level analysis can then help trace it back to code. A scan that misses key application states leaves their behavior untested. Conclusion DAST becomes most useful when the test reflects how the application is actually used. That means reaching meaningful user roles and the API routes behind them. Workflows that change session or authorization state also need coverage. As the application and its environment evolve, repeating those tests can show whether exposed behavior has shifted with them. Feauted image credit