# Dynamic Testing & API Security Dynamic Testing & API Security validates the security of **running applications** — testing how they actually behave under real-world conditions, not how their code looks at rest. It adds a critical "shift-right validation layer" that complements shift-left practices like SAST and SCA — catching vulnerabilities that only emerge when systems interact with real inputs, users, APIs, and external integrations. Modern applications are heavily API-driven and operate in highly interconnected environments — making them particularly vulnerable to runtime exploits such as injection attacks, authentication bypasses, misconfigured endpoints, and sensitive data exposure that no amount of static analysis can predict. {% hint style="info" %} Dynamic Testing & API Security ensures that what was built securely also behaves securely — validating application defense under real attack conditions before customer exposure. {% endhint %} ## DAST — Dynamic Application Security Testing DAST tests running applications from the outside — simulating how an attacker would interact with the system. It sends crafted inputs, monitors responses, and identifies exploitable vulnerabilities including SQL injection, XSS, authentication flaws, and runtime misconfigurations. OpsMx Delivery Shield integrates **OWASP ZAP** — enhanced with automated scanning, intercepting proxy, spidering, active/passive scanning, and fuzz testing — to provide continuous dynamic security validation against live application endpoints. ### **Why DAST Is Used in OpsMx** SAST and SCA catch code-level and dependency risks — but many vulnerabilities only appear at runtime. DAST completes the coverage picture by: * **Testing what attackers actually see** — live endpoints, session handling, authentication flows, and API responses * **Triggering automatically on every deployment** — every new image deployment via Argo CD, Spinnaker, or Jenkins initiates a DAST scan through the ZAP integrator * **Validating OWASP Top 10 coverage** — SQL injection, XSS, CSRF, broken authentication, sensitive data exposure, and more * **Supporting API security testing** — REST, SOAP, and GraphQL endpoints scanned via imported API definitions ### **Scan Types Supported** | Scan Type | Description | | -------------------------- | -------------------------------------------------------------------------------------------- | | **Passive Scan** | Monitors traffic for security issues — safe for production, no attack payloads sent | | **Active Scan** | Simulates SQL injection, XSS, command injection — for staging/pre-production | | **Authenticated Scan** | Tests internal functionality, RBAC, and user-specific vulnerabilities with valid credentials | | **Non-Authenticated Scan** | Tests public-facing components — login pages, public APIs | | **Ad Hoc Scan** | On-demand scan of any service URL directly from the dashboard | | **Fuzz Testing** | Tests API endpoints and form fields with varied payloads to find input validation flaws | ### **Key Capabilities** * **Intercepting Proxy** — analyzes and modifies requests/responses to uncover hidden vulnerabilities * **Spidering & Crawling** — maps entire application architecture, entry points, URLs, parameters, and forms * **Custom Scan Policies** — configure scan depth and scope per application risk profile * **Custom Scripts** — write rules in JavaScript, Python, or Groovy for organization-specific test scenarios * **Session Management Testing** — tracks session states, cookies, and tokens to uncover privilege escalation and logic bugs * **Multi-URL DAST** — scan multiple service endpoints in a single scan run when authentication is shared ### **Results Location in Delivery Shield** * **Post Deploy section of the DBOM page** — results tied to each deployment record * **Vulnerability Management page** — findings by severity with remediation guidance * **Top 5 Vulnerabilities tab** — immediate visibility into highest-risk runtime issues ## API Security API Security protects the APIs that serve as the backbone of modern application communication — ensuring that service-to-service interactions, external integrations, and user-facing endpoints are secured against unauthorized access, data leakage, injection attacks, and abuse. APIs are a major attack surface in microservices architectures. A single misconfigured or unprotected API endpoint can expose sensitive business logic, user data, or internal services. ### **Why API Security Is Used in OpsMx** OpsMx uses API Security in Delivery Shield to: * **Discover shadow and unmanaged APIs** — identifying endpoints that were never formally documented or secured * **Enforce authentication and authorization** — validating OAuth, JWT, and API key controls on every endpoint * **Detect input validation failures** — preventing injection attacks via malformed or malicious API inputs * **Protect against data exposure** — identifying APIs that return more data than the caller is entitled to * **Test GraphQL, REST, and SOAP APIs** — imported via OpenAPI/Swagger, WSDL, or GraphQL introspection ### **Key Aspects** | Control | Description | | ------------------------------------- | ----------------------------------------------------------------- | | **Authentication & Authorization** | OAuth 2.0, JWT validation, API key enforcement | | **Schema Validation** | Prevents malformed or malicious inputs at the API boundary | | **Rate Limiting & Abuse Protection** | Detects and blocks API abuse patterns | | **Sensitive Data Exposure Detection** | Flags APIs returning PII, credentials, or sensitive business data | | **API Inventory & Discovery** | Tracks all known and shadow API endpoints across the environment | ## Penetration Testing Penetration Testing goes beyond automated scanning by simulating **targeted, real-world attack scenarios** to identify exploitable weaknesses in applications and systems that automated tools alone cannot surface — including business logic flaws, chained exploits, and advanced attack paths. ### **Why Penetration Testing Is Used in OpsMx** Automated scanning answers "are there vulnerabilities?" Penetration Testing answers: * **Can an attacker actually exploit this vulnerability?** * **What is the potential impact of a successful attack?** * **How far can an attacker move within the system once inside?** OpsMx integrates penetration testing into its continuous security practices — combining automated dynamic testing with targeted deep assessments that validate whether security controls are effective in practice, not just in theory. ### **Key Capabilities** * **Business logic flaw detection** — exploiting application workflows that automated scanners miss * **Chained exploit identification** — finding multi-step attack paths that combine low-severity findings into critical risks * **Credential and session abuse testing** — validating authentication strength under real attack conditions * **Post-exploitation assessment** — determining lateral movement potential once initial access is achieved * **Compliance validation** — meeting PCI DSS, SOC 2, and other regulatory penetration testing mandates ### **Benefits for the User** * Validates that security controls work in practice — not just in design * Identifies exploitable vulnerabilities missed by DAST and SAST * Provides board-level and auditor-ready evidence of real-world security posture --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.opsmx.com/code-to-cloud-security-and-scanners/dynamic-testing-and-api-security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.