Welcome to the world of Dynamic Application Security Testing (DAST). When developers write software, they often focus on ensuring the code compiles and performs the desired functions correctly. However, a piece of software can look perfect in the source code but still behave dangerously when it is actually running on a server. There is often a gap between what we think the code does and how it reacts to unexpected input in a real-world environment.

In this course, we will bridge that gap. We will move beyond just looking at code files and start interacting with running applications to find security holes. We will learn how to automate attacks that mimic real hackers to identify weaknesses before bad actors do. By the end of this course, you will understand how to build and use tools that test your applications dynamically, ensuring they are secure not just in theory, but in practice.

Dynamic Application Security Testing, or DAST, is a method of security testing that analyzes an application while it is running. Unlike other testing methods that look at the source code or the architectural design, DAST treats the application like a black box. This means the tester (or the testing tool) does not know how the application is built inside. It only cares about the inputs it sends to the application and the outputs the application sends back.

This approach matters because it simulates the perspective of an external attacker. A real-world hacker usually does not have access to your source code. Instead, they interact with your website or API, trying to find open doors, weak passwords, or forms that accept malicious commands. DAST tools automate this process by sending thousands of different requests to your application to see if any of them cause a security failure.

Because DAST requires a running environment, it tests the entire application stack, including the web server, the database, and any third-party integrations. This "outside-in" perspective allows it to identify issues that arise only when these components interact under specific conditions. Whether you are testing a traditional monolithic web application or a modern set of microservices via their APIs, DAST provides a final layer of defense by verifying that the system as a whole behaves securely in a production-like setting.

Since DAST interacts with the running application, it can discover vulnerabilities that are invisible to static analysis. These are often categorized into four key areas. By testing the application in its live state, DAST provides a realistic view of how security flaws manifest when various components—like the database, server, and code—interact.

1. Runtime and Logic Vulnerabilities Runtime vulnerabilities are issues that only appear when the application is live and processing data.

• Business Logic Flaws: These occur when an attacker uses the application's legitimate functions in a way the developers didn't intend. For example, if a shopping cart allows you to change the quantity of an item to -1 to receive a refund, SAST might see the math as valid, but DAST will catch the resulting negative balance in the transaction.
• Insecure Direct Object References (IDOR): DAST can detect if changing a user_id in a URL allows one user to see another user's private data—a flaw that is notoriously difficult for static tools to map correctly.

2. Configuration and Environmental Issues Your code might be perfect, but the environment it lives in can be dangerous.

• Server Misconfiguration: If the web server is configured to allow directory listing (letting anyone see the files on the server) or allows access to .env files, SAST will miss it because that configuration exists in Nginx or Apache settings, not the application code.
• Security Headers & CORS: DAST checks the HTTP headers of the response. It identifies if your site lacks protection against Clickjacking (X-Frame-Options) or if it has an overly permissive Cross-Origin Resource Sharing (CORS) policy that allows malicious sites to steal data.

3. Session and Authentication Management DAST acts like a user, so it is uniquely positioned to test how the application handles "staying logged in."

• Cookie Security: It checks if session cookies are set with the Secure and HttpOnly flags.
• Session Fixation: It can verify if an application gives a user a new session ID after they log in, preventing attackers from "fixing" a session ID to hijack an account later.

4. Verification of Exploitability DAST is unique in its ability to verify exploitability. Just because a SAST tool flags a line of code as "potentially dangerous" does not mean it can actually be hacked; there might be a firewall or a secondary validation layer in place. DAST proves a vulnerability exists by successfully exploiting it (in a safe, controlled way). If a DAST scan reports a vulnerability, it usually means a real attacker could do the same thing, which significantly reduces "false positives."

In this lesson, we established that DAST is the practice of testing a running application from the outside in. We learned that while SAST analyzes the blueprint (source code), DAST analyzes the actual building (running app). This allows DAST to catch configuration errors, logic flaws, and verify that potential vulnerabilities are actually exploitable.

We also looked at the basic workflow of a DAST tool: crawling to find inputs and then auditing those inputs with malicious payloads. In the upcoming lessons, we will put these concepts into practice using industry-standard tools like OWASP ZAP and Nuclei. You will learn how to automate security scans from the command line, write custom vulnerability templates, configure authenticated scanning to test protected endpoints, and integrate DAST into CI/CD pipelines to catch vulnerabilities before they reach production.