Application security testing: what you should know

API security testing and next-generation DAST have had to evolve fast, because the web itself changed underneath them. No longer are we all just browsing a set of HTML files that security tools can easily crawl to find things to test. Instead, APIs have eaten the web, and security has struggled to keep up.

The two pillars of application security testing (AST), Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST), were built for an earlier web. Because of the introduction of modern web frameworks and APIs, DAST tools have been unable to find vulnerabilities the way they used to. SAST tools have always had issues with false positives, and with even being able to find vulnerabilities that only become obvious once the browser is involved.

The testing category has renamed itself repeatedly over those same years. The label matters far less than a concrete question you can put to any tool: given an application you did not document, can it find the endpoints, reach the fully authenticated states, and hand back evidence a developer can act on? That is the bar this guide uses throughout.

A second shift is now compounding the first. AI-assisted development means software no longer ships only from engineering. Developers build faster with coding agents such as Claude Code, Cursor, GitHub Copilot, and Windsurf, while finance, HR, and operations teams stand up dashboards, portals, low-code workflows, and AI-generated internal services of their own. Every one of those applications and APIs adds to a growing application attack surface, and it grows faster than any security team can inventory or test by hand.

This guide covers the fundamentals of application security testing, how the approaches differ and where each one is blind, and what testing has to look like when agents write, and fix, a growing share of the code. Pairing static analysis for API discovery with dynamic testing of the running application is one answer to that: used together, each covers the other’s blind spots.

What is application security testing (AST)?

No single approach sees everything. SAST reads code but cannot watch behavior; DAST watches behavior but cannot read code; SCA only knows about components someone has already catalogued. The most effective programs combine them, which is exactly the gap NightVision set out to close by pairing discovery-driven DAST with source-code analysis.

Types of application security testing

The four core AST approaches differ in what they analyze, when they run, and what they miss. They are complementary, not competing, which is why mature programs run more than one.

NightVision concentrates on discovery and DAST, then adds source-code analysis through API eNVy to widen testing with recognized routes from supported REST frameworks that maintained documentation or observed traffic may miss. See how the platform fits together.

SAST vs DAST: how do they differ?

SAST and DAST are the two pillars of application security testing, and the simplest way to tell them apart is when they run and what they can see. SAST reads your source code without executing it; DAST exercises the running application from the outside, the way an attacker would.

Because each one is blind exactly where the other sees clearly, NightVision’s thesis is to combine them rather than choose between them. See how the platform pairs discovery-driven DAST with source-code analysis.

How to choose an application security testing approach

There is no single “best” tool, only the right mix for your stack, your release cadence, and the kinds of flaws you most need to catch. As the Defense in Depth principle holds, SAST, DAST, IAST, and SCA each answer a different question, and the strongest programs run more than one. The framework below is meant to help you reason about where each approach earns its place, and where discovery-driven testing of the real, running attack surface (NightVision’s focus) tends to matter most for modern, API-heavy applications.

A practical decision framework

• Lean on SAST when you want to catch code-level flaws early. Static analysis reads source without running it, so it surfaces issues like SQL injection, cross-site scripting, and hardcoded secrets at the commit stage, before anything is deployed. Its trade-off is noise: pattern matching against code semantics produces false positives, and it struggles with runtime, auth, and business-logic issues that only appear once the app is live.
• Lean on DAST when you need to see what an attacker sees. Dynamic testing exercises the running application, so it finds runtime, configuration, authentication, and business-logic flaws that static analysis cannot observe. The catch is coverage: a DAST tool can only test the endpoints it can discover, which is exactly why discovery has to come first for API-first apps.
• Consider IAST when you can instrument the application. Interactive testing places an agent inside the running app, combining runtime context with code visibility and typically lowering false positives. It requires instrumentation and is language and runtime specific, so it fits best in test and QA environments where that overhead is acceptable. (NightVision does not sell an IAST product; we mention it for completeness.)
• Use SCA to govern your dependencies. Software composition analysis audits open-source and third-party components for known CVEs and license risk. It only knows about components someone has already catalogued, so it covers your dependencies, not your custom code. (NightVision does not sell an SCA product either; pair one alongside the approaches above.)
• Why combined coverage wins across the SDLC. No single approach sees everything: SAST reads code but cannot watch behavior, DAST watches behavior but cannot read code, and SCA only knows catalogued components. NightVision set out to close that gap by pairing discovery-driven DAST with source-code analysis (the product is API eNVy), so testing starts from the real, running attack surface and findings can be traced back toward the code that owns them. This is auth-focused source analysis paired with dynamic testing, not a full SAST suite, and it is most valuable where the two disciplines reinforce each other: discovering shadow endpoints in code, then exercising them live.

An evaluation checklist for buyers

When you compare tools, these are the axes that separate a scanner built for an earlier web from one built for distributed, API-first applications. Score each vendor honestly against your own apps.

• API discovery coverage, including shadow and undocumented endpoints. Does the tool enumerate the real attack surface, or does it test only what an OpenAPI file documents? Discovery that reads source code can surface shadow, zombie, and versioned endpoints that spec-only and crawl-only scanners never see.
• Auth and stateful-scan handling. Modern apps are session-bound and multi-step. Look for scripted login journeys that handle MFA, credentials held in a secrets vault, sessions that persist for the length of the scan, handling of multi-step forms, and a login check that fails the pipeline instead of silently scanning logged out. (How NightVision handles this: authenticated scanning.)
• Evidence quality and false-positive rate. Prefer findings backed by request and response artifacts and reproduction steps over pattern-only alerts. Code-traced linkage, where available, cuts triage time and routes fixes to the right owner.
• CI/CD integration. The tool should fit the pipeline with tunable modes (a fast PR check, a balanced run on main, a deeper scheduled scan off-hours) and respect rate limits and change windows so it does not disrupt production.
• Language coverage. Source-aware discovery is only useful if it speaks your stack. NightVision’s API eNVy covers Java, Python, JS/TS, .NET, Ruby, and PHP, with Go support; confirm any vendor covers the languages your services are actually written in.
• Compliance reporting. Check whether the tool maps cleanly to the OWASP API Security Top 10 (2023) and produces exportable, evidence-backed artifacts you can attach to SOC 2, PCI DSS, or federal control narratives.
• Agent readiness. A growing share of development runs through coding agents, so ask each vendor the question that separates a chat integration from a working loop: can your agent launch a scan, read the evidence, propose a fix, and verify it? Look for an MCP server or agent skills that expose scanning, findings, and per-finding evidence as tools an agent can call, with a human approving the resulting change. (How NightVision handles this: NightVision for coding agents.)

What is next-generation API security testing?

Next-generation API security testing is the practice of testing the full, real API attack surface of modern, distributed applications, including the endpoints that legacy scanners never discover. The shift in API security that’s happening now is a shift in focus from the low-level network established by the infrastructure supporting applications, to the higher-level network established by the applications as they’re deployed. For a modern, containerized, microservices-based application, the API forms a network. Its endpoints are not IP addresses but interfaces (the “I” in “API”). First-generation DAST does not perceive the entire API network, leaving a significant share of active endpoints untested. Developers often believe they’ve deprecated earlier versions of their APIs, when in fact they’re still operational.

Beyond the perimeter: Where is app security failing?

The failure is rarely the testing itself. It is the inventory the testing starts from. A scanner can only exercise the endpoints it knows exist, so when modern web frameworks and APIs hide routes from crawlers and specs, whole regions of the attack surface simply never get tested. DAST has also always struggled to identify business logic flaws that are complicated, multi-step, involve the DOM, or need human interaction.

Dynamic Application Security Testing (DAST), built for API-first apps

Modern apps are API-heavy, stateful, and dynamic. Legacy DASTs that “crawl and guess” miss large parts of the attack surface, struggle with auth and state, and bury teams in noise. This section covers what modern DAST must do and how to operationalize it next to API discovery and code-aware testing. For how NightVision itself implements these requirements, see web app DAST built for modern apps.

Why legacy DAST misses modern apps

• SPA & dynamic routing: Client-rendered routes hide content from naive crawlers; form flows and JS events gate critical paths.
• Auth & state drift: Sessions expire; CSRF/anti-automation defenses and MFA flows break scans; test data isn’t persisted between steps.
• API blind spots: Endpoints outside an OpenAPI file (shadow/legacy/versioned) go untested.
• Throughput vs. safety: Aggressive fuzzing trips WAF/rate limits and pollutes logs; timid scans under-cover.
• Alert fatigue: Pattern-only findings without exploit proof (and no code or request/response evidence) waste triage cycles.

What “next-gen DAST” looks like

1. API-aware discovery first. Pull endpoints from every source available (OpenAPI and Swagger specs, Postman collections, recorded traffic, and analysis of the source code itself), then feed that inventory into DAST so you test what actually exists, not just what’s documented.
2. Authenticated, stateful crawling that actually works. Scripted login journeys that survive MFA, credentials held in a secrets vault, sessions that persist across the scan, and multi-step forms that really submit. LLM-assisted form handling improves path coverage on validation-gated forms. A scanner that quietly falls back to unauthenticated crawling after a failed login is worse than one that fails loudly.
3. Test generation grounded in real check classes. An automated scanner earns its keep on the flaw classes that are reliably testable from the outside: injection (SQL, command, template), cross-site scripting, server-side request forgery, path traversal, CORS and security-header misconfiguration, JWT validation flaws, and known-CVE template checks. Context from discovery makes those checks targeted rather than blind fuzzing. Know the boundary, too: the OWASP API Security Top 10 (2023) is led by authorization flaws, Broken Object Level Authorization (BOLA, API1:2023), Broken Object Property Level Authorization (BOPLA, API3:2023, which absorbed mass assignment), and Broken Function Level Authorization (BFLA, API5:2023), and proving them requires multiple user identities plus knowledge of who should own which object. That remains largely a human penetration-testing discipline; treat any scanner’s claim of automated authorization testing with scrutiny.
4. Evidence on every finding. Demand the full request and response that produced each finding, with reproduction steps, so triage starts from artifacts instead of pattern-only alerts. Source linkage, where a finding can be traced toward the code that owns the route, cuts triage time further.
5. Coverage visibility. The scanner should show which discovered endpoints a scan actually exercised, so untested surface is a visible list rather than a silent gap that compounds across builds.
6. Pipeline-native controls. Scans should start from the pipeline, gate it on conditions the team chooses, and fail loudly when a login breaks instead of silently scanning logged out. Production safety comes from scanning staging and pre-production builds, not from hoping an aggressive scan behaves.
7. Agent-ready interfaces. The newest requirement: expose scans, findings, and evidence to any MCP-capable coding agent (Claude Code, Cursor, GitHub Copilot, Windsurf), so an agent can launch a scan, read the evidence, propose a fix, and verify it with a rescan, while a human approves the merge.

NightVision’s approach to DAST (how it fits your stack)

• Discovery → Test: NightVision’s API discovery (API eNVy) enumerates real endpoints, including shadow and versioned routes, and feeds that inventory directly into DAST so testing starts from reality, not a stale spec.
• Crawl that keeps up: Session-aware scanning with LLM-assisted form handling reduces stalls on login and multi-step flows, improving route coverage on SPAs and authenticated areas.
• Impact-first findings: Evidence-backed results (request/response artifacts and reproduction steps) cut triage time; optional code-trace mapping (when integrated) helps you send fixes to the right owners quickly.
• Built for CI/CD: Scans run from GitHub Actions, GitLab CI, Jenkins, Azure DevOps, and Bitbucket, with results landing as SARIF in GitHub Security Alerts and a login-check gate that fails the pipeline instead of scanning logged out.

Federal API security requirements (U.S.) and how NightVision helps

Public-sector teams have to secure modern, API-heavy apps and show alignment to Federal guidance. This section maps the major requirements to what NightVision does out-of-the-box. For a deeper, standalone walkthrough of each framework, see our companion guide to federal API security requirements.

NightVision at a glance for regulated teams

• API eNVy (static): Automatically generates OpenAPI specs by scanning source code. No run or compile needed; uncovers shadow/undocumented endpoints and version drift; syncs with GitHub/GitLab/Bitbucket for continuous coverage.
• Language coverage: Java, Python, JS/TS, .NET, Ruby, PHP, and Go.
• Gray-box testing: Discovery-driven DAST with auth/state handling for accurate findings.
• Auth gaps: Flags missing or weak authentication and can auto-open PRs to remediate.

Requirement-by-requirement mapping

NIST SP 800-204 Series (microservices/API security)

What it asks for: Secure microservices with gateways/meshes, policy enforcement, and strong authz (ABAC), and integrate DevSecOps practices across code, infra, policy, and observability. (NIST Computer Security Resource Center)

How NightVision helps:

• API eNVy extracts real endpoints from code to seed gateway/mesh policy and generate OpenAPI, improving least-privilege routing and policy scope.
• DAST exercises those endpoints (including authentication paths) and provides request/response evidence teams can use when tuning secure-by-default gateway rules and access policies. On why that evidence has to come from the deployed path rather than application source, see Reverse Proxy Access Control Testing.
• Testing through the deployed path also covers defects that exist only in the composition of two components, where each configuration is correct on its own. For a worked example, see Web Cache Deception on what happens when a cache and an application disagree about where a URL ends.

CISA Zero Trust Maturity Model (ZTMM v2.0)

What it asks for: Mature across Identity, Devices, Networks, Applications & Workloads, and Data; treat apps as internet-accessible, enforce strong auth, encrypt traffic, and continuously monitor and test. (CISA)

How NightVision helps:

• Applications & Workloads: Discovery-led DAST provides “rigorous empirical testing” inputs and coverage reporting.
• Data & Visibility: Request/response evidence and logs plug into SIEM/SOAR for continuous monitoring and ATO packages.

FedRAMP (NIST 800-53 Rev. 5-based)

What it asks for: Meet 800-53 Rev. 5 control baselines and ConMon requirements (e.g., AC, AU, CM, SC, SI families); maintain logging/monitoring, vulnerability management, and secure engineering practices. (fedramp.gov)

How NightVision helps:

• Controls alignment: Evidence-backed findings and exportable artifacts support AU/SI control narratives; static and dynamic coverage supports AC (authz), CM (change), and SC (secure comms) discussions in SSPs and annual assessments.

Executive Order 14028 (Improving the Nation’s Cybersecurity)

What it asks for: Secure software development, automated vulnerability discovery and remediation, EDR, robust logging, and SBOM practices; greater real-world testing and coordinated disclosure.

How NightVision helps:

• DAST produces reproducible exploit evidence and aligns with “test like an adversary.”
• API eNVy helps maintain accurate API inventories and specs that support SBOM and dependency provenance across services.

OMB M-22-09 (Federal Zero Trust Strategy)

What it asks for: Phishing-resistant MFA, encrypt internal DNS/HTTP, treat apps as internet-accessible, and routinely subject applications to rigorous empirical testing while welcoming external reports. (The White House)

How NightVision helps:

• Gray-box DAST operationalizes the memo’s “empirical testing” requirement and produces artifacts for POA&Ms and governance.
• API eNVy keeps the application inventory and current endpoints in sync with gateway policies as apps move to internet-accessible postures.

Shadow APIs, rogue endpoints, and denial-of-wallet attacks

Undocumented endpoints are the clearest case of testing what you did not know you had. For how teams operationalize this, see shadow API detection and API inventory integrity.

Beyond formal compliance frameworks, two classes of problem define the modern API attack surface: endpoints that no one is tracking, and requests engineered to run up your bill. Both are invisible to tools that only test what a spec or a crawl already knows about.

Shadow, zombie, ghost, or orphan APIs

Shadow, zombie, ghost, and orphan APIs are undocumented or deprecated endpoints that remain live and reachable but are missing from an application’s official API inventory. When an automated documentation process such as Swagger visualizes API endpoints in an application, it can miss a surprisingly large number of active points for a number of shockingly understandable reasons:

• Developers may intentionally build secret APIs into a system for testing or development purposes, then leave them in the source code (shadow APIs).
• Organizations may have deprecated previously authentic APIs or replaced them with new versions when they update their applications, without removing the older versions, sometimes intentionally, for instance to ensure downward compatibility with older applications still installed in the field (zombie APIs).

Both of these categories are often also referred to as rogue APIs. A SAST tool that scans for API endpoints from source code, and a DAST tool whose map of all endpoints in an application comes from Swagger documentation, will naturally fail to uncover rogue APIs. As a result, the most vulnerable endpoints in an application, the ones a malicious actor wants to concentrate on anyway, will go unrecognized.

Denial-of-Wallet (DoW) attacks

A denial-of-wallet (DoW) attack drives up a target’s cloud bill by flooding metered, serverless endpoints with expensive requests until the cost itself becomes the damage. One of OWASP’s Top 10 API security vulnerabilities is catalogued as Unrestricted Resource Consumption, referring to the ability of code, malicious or benign, to overtax endpoints with deluges of requests. One pattern for a request that may be used in such a deluge is a deeply nested GraphQL resource request, such as for alternating properties of an object, like this:

query {
  titles {
    authors {
      titles {
        authors {
          titles {
            authors {
              titles {
                authors {
                  name
                }
              }
            }
          }
        }
      }
    }
  }
}

An API gateway whose query depth limit is manually set to 3 would thwart the execution of the above GraphQL query. But managed API gateways are typically billed per request, so each invocation can incur a charge even when the request is ultimately rejected. (Self-hosted gateways such as Kong, nginx, or Envoy shift that cost to infrastructure you run rather than removing it.) It’s like a robotic security guard that sends you a bill each time it gets kicked. A SAST scanner should be able to spot such an egregious example as the code fragment above. However, if the GraphQL query were constructed dynamically (for instance, through the insertion of conditional directives such as @include), you’d need to execute the code to see exactly how much depth the query reached.

As a result, a denial-of-wallet attack (DoW) could be easily constructed using an unrestricted number of simultaneous queries, each of which kick the gateway, with each kick incurring a charge. Another layer of response could be to set a rate limiter or throttler to a reasonable cap, such as 100 requests per IP address per minute. The way around that obstruction would be to make the DoW attack distributed (DDoW), and then deploy the attack from multiple addresses. And because throttling is applied at the gateway, it protects the expensive compute behind the gateway without necessarily eliminating the per-request cost of the rejected calls themselves. That is what makes denial-of-wallet awkward to mitigate with rate limiting alone.

What makes modern API security “next-generation?”

API development has always been about validating inputs, authenticating users, encrypting sensitive information, and observing and adhering to permissions. In the early 2000s, the prevailing model of networked applications was called web services, to distinguish them from what was still being considered “real software.” At that time, the prevailing methodology for web services communication was SOAP, a messaging protocol based around XML.

When the WS-Security model for SOAP was first conceived, its champions initially touted their proposed strategy as “comprehensive.” (PDF) When the model was first published, however, its initial practitioners conceded, “It is not feasible to provide a comprehensive list of security considerations for such an extensible set of mechanisms.”

Modern API security is more comprehensive because it pays closer attention to the then-unforeseen deficiencies introduced to the network by SOAP, and that could easily have been continued by REST and GraphQL. Here’s how some of the significant evolutionary changes address the elements that API security of the past missed:

• Direct fault observation: SOAP set a precedent for producing error messages (“Fault Response Messages”) that were, in their own way, comprehensive. They were so descriptive of what went wrong that a malicious actor could infer quite a bit about the profile of the entire network. GraphQL recognized this open window of exploitability right away. But its developers’ suggestion that detailed error information only be revealed to properly authenticated roles has inadvertently led to reliance upon logging and event management, which at the outset were rather haphazard. A multi-billion dollar industry emerged from managing security event logs. Next-generation API security recognizes that bad behavior incidents will often fail to make the log, no matter how comprehensive the log management system may be. Faults need to be observed, not just recorded, so that protection may be delivered at runtime. DAST is built around direct observability, flagging faults and bad behavior as they happen, and spotting them in action before they are released to production.
• Context-aware protection: REST made it feasible for a malicious actor with two or more active accounts to retrieve an object’s parameters with one account, then supplement a request using those parameters on another account to feign privileges to make higher-order, restricted requests. The phenomenon of insecure direct object references (IDOR), the legacy term for what the OWASP API Security Top 10 (2023) now calls Broken Object Level Authorization (BOLA), has historically been one of OWASP’s more common API security quirks. The logic behind it can be masked so effectively that SAST misses it altogether, and because proving it requires multiple user identities and knowledge of who should own which object, it remains largely a human penetration-testing discipline. What automated testing can do is shrink the ground it grows in: flagging the verbose error responses, weak token validation, and permissive cross-origin policies that hand an attacker the identifiers and the reach the attack needs. On that last one, the header worth reading twice is not the one most reports flag: see CORS Misconfiguration: The Wildcard Is Not the Risk.
• Perception past the perimeter: While web application firewalls (WAF) were originally marketed to offer deep visibility into API traffic over the network, many WAF components utilize packet sampling to monitor traffic behavior, rather than examining every packet. When traffic bottlenecks become an issue, DevSecOps personnel have been known to reconfigure their WAFs to allow some encrypted traffic to pass through unchecked, especially if it has a large packet size. Malicious actors exploit this tendency by generating synthetic requests with oversized headers. Modern API security enables an additional layer of application-level security, including by enabling signals and monitoring to be embedded in the application code itself.

In recent years, API development has incorporated the notions of mapping HTTP routes to secure methods, pre-evaluating data for the presence of commands to thwart injections, and assessing output data before it’s rendered to ensure its adherence to compliance frameworks. The key principle of next-generation API security that distinguishes it from previous incarnations is the enablement of fuller visibility into security incorporation and validation processes. Rather than having faith that everything should come out reasonably okay at the end, next-generation API security illuminates defects and bad behavior at their inception.

With every new generation of API security, its practitioners assert themselves by declaring that now they embrace greater visibility, whereas they didn’t before. This may not be the last time this happens. The visibility that’s being incorporated with this latest round embraces a new awareness that the interface of the application (the “I” part of “API”) may cover a far wider span of functions and methods than its developers and maintainers believe it does, and more than they would assert they designed it to have. Once an application becomes distributed and networked, it morphs into its own beast. Clever individuals may craft permutations of requests that no developer ever intended to design or activate. An application’s API is the entirety of the addressable network that it generates and supports, including the parts that were deployed intentionally and the other parts that happened to find their way there organically.

The key tenets of next-generation API security testing

There are two aspects of cybersecurity that a renewed attention to the integrity of the API will directly benefit. The first, obviously, is API security. In this respect, we mean the ability of the interface of a networked, usually distributed, application to facilitate access to data and functionality without endangering the integrity of the system, and without providing unauthorized access to privileged data and functionality to an unverified or non-authentic party. Keep in mind, an API does not have to be defective to be insecure.

The second is the broader domain of application security, which refers to the integrity and efficiency of the programs, along with the platforms and infrastructure that support them. An application’s security may be threatened when its API is vulnerable. So there is a separate realm of application security testing, covered later in this article, that embodies applying first principles to strengthen application code, protecting it from exposure to vulnerability by insecure APIs.

API discovery and inventory management

From the perspective of anything that could breach the integrity of an API, whether maliciously or incidentally, an API presents itself as an attack surface. It is not so much a wall that may or may not be penetrated to some extent, but a programmatic structure where information transactions take place. Comprehending the structure and dynamics of this wall requires us to adopt a rational, relatable set of metrics.

An API inventory is not just a list of function calls or the output from a Swagger scan. The sensitivity of each API function to being probed or prodded directly maps to the level of risk the organization assumes by exposing that function. An API need not be vulnerable to be sensitive. Risk occurs whenever an API is capable of divulging information that could conceivably be weaponized against the organization, or misused somehow to its detriment. This is true even if the API performs precisely as designed and maintains, by any measure, the highest integrity.

So a proper API inventory process is an evaluation of how much its existence exposes the organization to risk. The presence of any rogue API function, any endpoint that communicates information in a way that’s not being monitored and that is not traceable and auditable, is a threat to the organization even if that function technically does not constitute a vulnerability. It’s like having a headquarters building with doors you don’t know are there, so you never think about locking them.

What makes the task of API discovery so confusing for a great many people is the ongoing disagreement over the fundamental question of whether an API is a singularity or a collective. When the concept was first introduced to network computing in the late 1980s, an API was a library of accessible functions, each of which was accessed via a remote procedure call. In common conversation among developers, an individual endpoint that responds to HTTP POST and GET requests could be an API, and the collection of all such endpoints constitutes all of the organization’s APIs. Either definition is perfectly sensible, although if there were only one, we’d be a lot better off. Although this may seem like nitpicking, security engineers have stated for the record that the issue of API nomenclature is the first and foremost sticking point preventing organizations from finally getting a handle on the API discovery process.

To make sense to both groups of API practitioners, the concept of API discovery must embody a complete reconnaissance of the communications structure of the application. This investigation must turn up all of the following:

• The complete route with which each function is addressed, including the fully-qualified domain name (FQDN), the method name, and subsequent paths
• The identities of the physical host servers and virtual containers that support the complete API
• All the integrations made by vendors, suppliers, and the organization’s own developers that have shifted the functionality of the API library beyond its original profile (and which may, in turn, have led to older, defunct, though still operable endpoints accessible as rogue APIs)
• The inclusion, location, and protection of all active, machine-readable specifications using OpenAPI (Swagger), RAML, API Blueprint, or other formats, that once acquired and parsed may serve as maps for the entire API structure, including active and rogue endpoints

A complete API inventory management regimen that follows from the discovery process should document the following:

• The identities of applications to which API requests are mapped
• The identity, structure, format, and sensitivity levels of the data which API functions return
• The identities of the roles and/or individuals who have responsibility for managing the data that API functions transact

Advanced API security testing

Penetration testing (“pentesting”) of modern applications does not necessarily mean exploiting them in production under black-hat scenarios. NightVision’s DAST implements a kind of penetration testing: point it at a build of your application running in your own secure, publicly inaccessible staging environment (including on private networks, via Smart Proxy) and it interacts directly with the API in a live setting, scanning for compromised functions and observing all logging and outputs, without endangering or compromising the application in production.

No DAST tool, however, is a complete replacement for a professional offensive security test. Automated coverage of the repeatable classes is what buys human testers time for the novel ones, which is the model described in pentester acceleration. NightVision works with offensive security partners who provide staged API vulnerability examinations and full penetration-testing engagements alongside continuous automated scanning. See NightVision partners.

Inside organizations, DevSecOps personnel may stage live penetration tests of API-accessible applications using a variety of tools, including:

• Burp Suite, whose Community Edition includes a proxy server for simulated attacks that intercepts HTTPS traffic and facilitates inspection and live modification of requests and responses, plus whose commercial edition includes an automated vulnerability scanner that audits requests for common exploits such as cross-site scripting (XSS) and SQL injection
• Zed Attack Proxy (ZAP), which implements a manipulator-in-the-middle between the application and browser, intercepting and modifying messages for experimentation purposes before forwarding them towards their intended destination
• Fuzz Faster you Fool (Ffuf), which is a fuzzing tool that utilizes brute-force methods to identify hidden, exploitable directories, paths, routes, and files, producing verbose reports of their results and findings
• Wfuzz, which is another fuzzing tool that analyzes HTTP requests and systematically replaces all references to the word FUZZ with permutations of parameters, authentication tokens, common names of files and directories, and information often found in request headers, to determine whether susceptible APIs will act on those mangled requests by attempting to parse them
• NightVision, which we believe takes many of the strengths of the point-and-shoot tools above and strips them of their weaknesses with our pairing of DAST and static source-code analysis, which works faster and more accurately, and fits seamlessly into the CI/CD pipeline.

For a side-by-side look at how NightVision stacks up against these tools, see our tool comparisons, including NightVision vs. Burp Suite.

API Security Posture Management (ASPM)

APIs are not exclusively usable the way they were designed or intended. API discovery applied on a continual basis enables an organization to maintain a complete assessment of how its application functionality is accessible, and through what means.

The information collected through API discovery should not only be kept and used by developers. Security and DevSecOps personnel charged with oversight of risk management will also benefit from what discovery reveals about the integrity of the application network. API Security Posture Management (ASPM) refers to a method for making API discovery information actionable in the risk management and compliance processes.

NIST CSF 2.0

The US National Institute of Standards and Technology’s Cybersecurity Framework (CSF 2.0) isn’t a law or set of regulations, but rather a means for organizations to visualize cybersecurity goals in a common manner, and implement a common methodology to address them. CSF 2.0’s six core functions (Govern, Identify, Protect, Detect, Respond, and Recover) map directly to best practices for implementing and maintaining API security through discovery.

SOC 2

SOC 2 is an independent attestation, not a self-assessment. A licensed CPA firm examines an organization’s controls against the AICPA Trust Services Criteria and issues a report: a Type 1 covering control design at a point in time, or a Type 2 covering operating effectiveness across a review period, typically three to twelve months. The criteria span five categories: Security, Availability (which includes the availability of functionality exposed through APIs), Processing Integrity, Confidentiality, and Privacy.

Application and API testing evidence feeds several of those criteria directly. Authentication handling, error handling, and access control are all areas where an auditor asks how you know the control works, and evidence-backed findings from testing the running application answer that question better than a policy document does. A current API inventory matters for the same reason: controls can only be evidenced across the surface you know about. NightVision itself holds SOC 2 Type 2, and the report is available under NDA.

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a private contractual standard, not a government regulation. The major card brands created the PCI Security Standards Council to maintain it, and it is enforced through the contracts merchants and processors sign with their acquiring banks, which is also how penalties for non-compliance flow. Requirement 6.2.3 covers the review of custom software before it is released to production, and requirement 11.3 covers vulnerability testing of systems in scope.

The need for API security is amplified greatly by the fact that developers frequently customize their API endpoints for the needs of their organizations, facilitating data exchanges and transactions that are particular to their needs without needing to alter the core source code. When organizations that process financial transactions fully comply with PCI DSS, they establish a working environment that essentially necessitates the creation and adoption of API coding best practices. A programmatic approach to API security requires direct observation of API behavior in action. SAST alone won’t cut it.

The key tenets of next-generation application security testing

If you apply next-generation API security at the proper stage of the application lifecycle (a stage we argue is further “left” in the process), then the real payoff comes from the ability to inform the application’s architecture early in its development. A human code architect has the mandate to imbue an application with fundamental coding principles for security and integrity. Modern API security, applied during the design and staging phases of development (not just the production phase), can and should guide decisions about how better to apply these principles. This way, once the application is fully built and deployed into production, its security becomes tighter, observable, predictable, measurable, and extensible.

What is a secure application?

First and foremost, a secure application avoids misusing data. By “misuse” in this context, we mean enabling any entity (user or agent) to utilize data for purposes for which that entity is not authorized, or to do damage to the application, or to harm the application’s underlying network and infrastructure. There’s a variety of potential disruptions that can occur: denial of service, unauthorized access, disruption of infrastructure, even conceivably the collapse of the entire system. All of these potential outcomes begin with misuse of data.

There is a circle of thought which maintains that, once the developers of an application have achieved a desired state of API security, developers can rest assured the application has access solely to the data to which it is already entitled. Type checking would no longer be something the application needs to do, for example, because the API would have already taken care of that. In fact, this assertion has been offered more than once as a definition of shift-left: catching vulnerabilities at the API before they reach the application core. An extended form of this argument is something you may have read before elsewhere, and on first read it does seem persuasive: integrating automated security tools and policies into the CI/CD workflow, including adding SAST and DAST, enables developers to focus on crafting business logic without being “dragged down” with security issues.

Sensing there may be some trouble with that interpretation, competitors have put forth an alternative approach: SAST, they argue, has been the poster child for shift-left, thus because SAST is ineffective by itself, shift-left is ineffective as an ideal. As this line of reasoning continues, since DAST is capable of detecting a greater number of vulnerabilities, both known and unknown, at runtime (a.k.a. in production), a so-called “DAST-first” approach would actually shift security right in the SDLC model, waiting until the code is completely built and staged, then observing production behavior very closely in keeping with a “fail fast” mindset. This is often cited by practitioners of the “build early, build often” approach to so-called accelerated DevOps, and has on occasion been co-opted by subscribers to the Agile framework.

One of the classic texts on this topic, API Security in Action by Neil Madden, defines it as the intersection between application security, network security, and information security. Although this is not technically wrong, a more updated interpretation should perhaps take into account an emerging reality: while API security is a common factor of all three practices, it is not a subset of any of them. Rather, API security should inform the application, including giving it the tools and resources it requires to ensure for itself that it is fulfilling its first mission: avoiding misuse of the data.

Integrating API security into the SDLC

There has long been a professed ideal that true software security and integrity begins at the design phase. Yet developers have not always had the tools and resources that would enable them to envision what code integrity should look like to start with, or to observe bad behavior for themselves before their code is ever deployed to production.

A holistic approach to security, in the context of modern API security, enables a developer to make adaptations and corrections to their code much closer to their “first drafts.”

The traditional SDLC is, ironically, not depicted as a cycle at all but rather a six-phase linear itinerary. Planning is at the beginning of this line, and deployment at the end. Whenever technologists are forced to consider the SDLC as genuinely cyclical, they will begrudgingly concede that software development is indeed continuous as the word “cycle” suggests. From there, they will eventually accept that security is ideally integrated into each stage of the cycle, and when they’ve finally achieved peak honesty, they’ll admit that security truly encompasses the cycle in its entirety.

In an environment where security is only given any consideration whatsoever after software has been deployed into production, security actually plays no part in the SDLC. Once security is given the serious attention it requires to positively influence the architecture of software, then security becomes a factor in every stage of the SDLC. Yes, the true degree of security of any amount of code may only be gauged when that code is executed. Yet that execution can be engineered to take place much earlier in the development process, even before the typical testing and staging phases in DevOps, in a limited and secure environment only the developer needs to see. In this sense, where the developer is finally allowed to think about security without risk of offending other people in the organization paid to be “the security guys,” we can say the organization thinks about security earlier than before. For this reason (again, for the left-to-right readers among us), you will hear that this ideal is responsible for shifting security left.

Perhaps more accurately, a holistic approach to security shifts this mindset left, right, up, and down. It acknowledges that security is integral to thinking about code, as opposed to an afterthought that comes up once code is deployed. It only makes sense that a security tool should help developers to think about their code better.

Where API security enriches application coding principles

The ideal to which the shift-left concept points is to enable security principles to be baked into code at its inception. The effectiveness of this capability cannot be estimated or assumed. It may only be measured directly, which is why next-generation API security is crucial to this effort.

Principle of Least Privilege (POLP)

When articulated properly, the Principle of Least Privilege asserts that no entity is ever given more authority or access than is necessary for it to perform its task, and no authorized human user is delegated more accessibility than is required for that user to fulfill their designated role.

The implications of this principle are too often unspoken. What POLP means is that there is no entitlement in a properly secured system. This contradicts the assertion made by proponents of role-based access control (RBAC) that the institution of roles makes it easy to designate access to users or entities based on what their anticipated level of usage entitles them to. “Traditionally,” writes the AWS DevOps & Developer Productivity Blog, “customers have used RBAC to manage entitlements within their applications. The application controls what user can do, based on the roles they are assigned.”

No application can simultaneously adhere to the idea that an application can delegate entitlements to users or authenticated entities in advance using three or four general accessibility levels of RBAC, and to the Principle of Least Privilege. It might not be possible or practical for an API to acknowledge hundreds of individual access rights, or separate Access Control Lists (ACL), for each entity granted access to a system. RBAC is a necessary thing, at least in the beginning. Next-generation API security makes it feasible for a developer to design roles that are more granular and that are a tighter fit for different classes of user, especially as newer classes become necessary over time.

It may mean there are more classes of user to consider. Yet a dynamic permissions system, used in conjunction with an identity and access management (IAM) system for microservices applications, can be made to scale across service domains. This makes it possible for the IAM to tailor new, more refined, and more applicable roles dynamically as the application deployment evolves organically, without the application needing to be re-architected, and without having to re-engineer API security.

This preceding paragraph might have actually described policy-based access control (PBAC), where the concept of the role is replaced by a kind of working, dynamic contract between the user/entity and the application. So be it. PBAC may be what RBAC must evolve into, to ensure that a growing number of classes are always assigned the minimum privilege possible.

Next-generation API security gives developers a way to observe application behavior at a very deep level, informing them as to the extent to which certain pre-defined security roles may be too loose for a new and emerging class of user. Networked, distributed applications have a tendency to evolve as they scale up and scale out. The architectural models that depicted their operations while they were being prototyped may no longer be applicable once their deployments have become mature. This is one of a multitude of reasons why continual API behavior observation has become absolutely critical for modern web applications.

Zero-Trust Security Model

You may have read an argument made by security vendors in recent years that the zero-trust ideal and the API security ideal are incompatible. The reason, they assert, is because zero-trust is about denying access as opposed to restricting access, while API security is about granting access.

This is a misinterpretation. A reasonable conclusion to be drawn by anyone reading NIST’s seven tenets of zero-trust (PDF) would be the following:

• All accessibility is ascertained and delegated only at the time it is required
• Any entity may only be granted access to resources when that access is required, after which time that grant is revoked (once again, there is no entitlement)
• All policies granting and denying access are dynamic and continually reviewed, as a result of all transactions and network activity being continuously monitored
• Systems are capable of improving their own capability to provide and deny access and authentication based on the activity they are monitoring

That last conclusion might sound like zero-trust requires AI to be practicable, and indeed it seems like AI would certainly help. What is clearly necessary in order to bring about this more accurately interpreted ideal of zero-trust is that API security must be proactive, constant, and vigilant. Put another way, it can’t be done automatically. It is an “eyes-on” mission.

Defense in Depth (DiD)

The non-profit Center for Internet Security (CIS) embraces the concept of Defense in Depth, acknowledging that no single security mechanism or methodology ensures absolute safety, but all of them together (or at least, as many as may be compatible with one another) is worth whatever redundancy that may result. So while a Google or YouTube search may uncover a multitude of “showdown” comparisons between SAST and DAST, or DAST and WAF, asking the perennial question, “Which should you choose?” DiD maintains that no single technology is a choice, but rather a necessity.

SAST and DAST both have significant roles to play in application security testing. SAST does not scan live applications but rather source code, searching for patterns between application code fragments and recorded patterns associated with known, catalogued vulnerabilities. That’s essentially the definition of code-level security. This code is not executed, so SAST is not looking for behavior patterns, but instead suspicious semantics. DAST exposes suspicious behaviors. A Defense in Depth approach to architecture maintains that, since both SAST and DAST have separate, useful roles to play, then both have a place in an application’s overall security.

Microsegmentation

One of the security practices that Defense in Depth legitimizes and promotes is microsegmentation. At its inception, this methodology was about maximizing the modularity of applications, and separating the interaction between those modules with a web application firewall. This way, access to functions could be granted or denied at a very granular level. Arguably, if an application is finely segmented, a less granular RBAC scheme may be effective enough at granting and denying access to individual functions without having to update policy each time.

Microsegmentation is typically introduced to newcomers to the topic by explaining it reduces the attack surface of an application. This is about as sensible as arguing that a semi-trailer truck, by virtue of being constructed using a greater number of parts, is far less likely to be struck on the highway by another vehicle.

As mentioned earlier, insecure direct object references (BOLA in the OWASP API Security Top 10 2023) is one of OWASP’s ten most common means of bypassing API security. IDOR is accomplished by attacking more than one API endpoint at a time, using the information gleaned through one interaction, often through brute force, as parameters (direct object references) in one or more other interactions. The endpoint is susceptible to assuming that the values for these parameters were obtained legitimately, and thus presumes the agent in the transaction was legitimately authorized. Obviously, the means of penetrating a microsegmented application is to attack a plurality of segments simultaneously and leverage the confusion generated in the process. Making the targets smaller, as things turned out, only made the attack surface larger. For the distinction underneath this whole class of flaw, and how to assert it in tests you own, see Authentication Is Not Authorization. The same failure has a property-level twin, where the caller writes a field of their own record that only the server should set: see Mass Assignment: How a Signup Form Creates an Admin Account.

Underneath all of it sits the credential the caller presents, and in most modern APIs that is a signed token whose claims a server can read without ever proving who wrote them: see JWT Validation: Decoding a Token Is Not Verifying It for the five assertions that sentence hides. Granular permissions and authentication checking is still a good idea, but not for the reason originally concocted. When you adopt a Defense in Depth approach and supplement your WAFs with next-generation API security, you have the means for every segment of your application, no matter how macro or micro it may be, to continually validate permissions and authorities for users and entities as traffic flows between segments. Validating continually is also the only way to know an access control is enforced rather than merely declared, which is the argument in MFA Enforcement Testing: Policy vs. the Live Endpoint.

Application security testing in the age of AI-assisted development

AI-assisted development changes application security testing in two ways at once. Developers now drive testing through coding agents that can launch scans, read evidence, and draft fixes. And people who are not developers now ship software of their own, adding to a growing application attack surface faster than any security team can inventory it by hand.

Those are two different audiences with two different relationships to security tooling, and a modern AST program has to serve both. The first audience uses the tools. The second never will, and the program has to cover their output anyway. In both cases the buyer, and the reviewer, is the AppSec team: same team, far more surface.

Developers drive testing through coding agents

For engineering teams, the change is where testing runs, not who is responsible for it. Any MCP-capable coding agent, including Claude Code, Cursor, GitHub Copilot, and Windsurf, can operate an agent-ready scanner directly: start a scan against the running build, pull the findings, read the request and response evidence for each one, draft a remediation, and rescan to confirm the finding is gone.

The division of labor matters more than the novelty. The scan itself stays deterministic, so two runs against the same build produce the same findings backed by the same evidence, which is what makes an agent’s fix verifiable rather than merely plausible. The agent works the loop; a human reviews the change and approves the merge. Determinism on the finding, agents on the fix, humans on the merge.

Builders outside engineering are a source of surface, not users

The second audience will never open a scanner, and no amount of enablement will change that. Finance teams stand up dashboards. HR wires portals to vendor APIs. Operations builds low-code workflows, and internal tools get vibe-coded or generated outright by agents. Each of these is a real application with real endpoints, often handling real data, and almost none of them enter a security backlog on their own.

Expecting these builders to run security tooling is the wrong model. The workable model treats their output as attack surface for the AppSec team to onboard and test, through the same pipeline that covers engineering’s applications. The test of an AST program is whether it can reach an application whose builder will never attend a security review.

Four ways in, one engine underneath

What bridges the two audiences is how testing reaches each application. There are four ways in, and a coherent program uses all of them: black box, where a URL and credentials are enough to test any reachable app, including the ones built outside engineering; gray box, where source-assisted discovery feeds the scanner endpoints no crawl or spec would reveal; CI/CD, where scans run in the pipeline on every build; and agent-native, where a coding agent drives the same operations over MCP. The same engine, the same checks, and the same evidence sit underneath all four, so a finding means the same thing no matter which door it came through.

The result is one program instead of two. Engineering adopts the entry points that fit its workflow, from CI/CD to agent-native. AppSec uses black box and gray box to cover everything else, including the applications that never came through an engineering pipeline. Coverage stops depending on who built the app or whether they knew a security team existed.

The imperative: secure the growing application attack surface

Every team ships applications now. Engineering ships faster with coding agents, and finance, HR, and operations ship software of their own. The application attack surface grows with every one of them, and coverage decays silently: security dashboards stay green not because the apps are safe, but because the newest apps were never onboarded.

That is the standard to hold an application security testing program to. It should discover applications and endpoints before it tests them, so the inventory reflects what actually runs. It should test the fully authenticated application, because that is where the data lives. It should hand back findings with the request and response evidence that makes them fixable, whether the fix is written by a developer or drafted by their agent and reviewed by a human. And it should reach every application through whichever door fits: black box, gray box, CI/CD, or agent-native.

Security testing that covers only the applications someone remembered to register is not coverage. Schedule a demo with a NightVision security engineer to see what discovery-driven, evidence-backed testing looks like against your growing application attack surface, or compare plans to start on your own.

Frequently asked questions

Can DAST test API endpoints that aren't in my OpenAPI spec?

Only if the scanner discovers them first. A legacy DAST that relies on a spec or a crawl tests what is documented, and that leaves shadow, versioned, and deprecated routes untested. NightVision starts from API discovery that reads source code to enumerate the real endpoints, including those missing from any spec, then feeds that inventory into DAST. You test the attack surface that actually exists, not a stale OpenAPI file.

What are shadow APIs and zombie APIs?

Shadow and zombie APIs are live, reachable endpoints absent from an application's official inventory. Shadow APIs are undocumented routes, while zombie APIs are older versions left operational. Maintained specs and traffic samples can miss them, so teams should combine inventory sources and test the running application.

What is a denial-of-wallet attack?

A denial-of-wallet (DoW) attack drives up a target's cloud bill by flooding metered, serverless endpoints with expensive requests until the cost itself becomes the damage. It maps to the OWASP API Security Top 10 (2023) category Unrestricted Resource Consumption (API4:2023). Static scanning can flag obvious examples, but dynamically constructed requests (for instance a deeply nested GraphQL query built with conditional directives) often have to be executed to reveal their true cost, which is where dynamic testing helps.

Does a DAST tool replace penetration testing?

No. NightVision's discovery-driven DAST automates a great deal of attack-style testing, runs continuously in CI/CD, and produces reproducible evidence, but no automated scanner is a complete replacement for a professional offensive security engagement. Pentesters bring creativity, chained business-logic exploitation, and human judgment that tooling cannot fully reproduce. Multi-user authorization testing in particular, proving that user A can reach user B’s objects (BOLA) or call functions reserved for admins (BFLA), depends on knowing who should own what, and remains largely a human discipline. The practical model is to let DAST catch the common, repeatable issues every build so human testers can focus their time on the deeper, novel attack paths. The same logic now applies to AI: an autonomous pentester still needs reproducible evidence and a human gate on the fix, which we cover in Autonomous Penetration Testing: A CISO Reality Check. For a side-by-side breakdown of what each approach actually proves, and where PCI DSS treats scanning and pentesting as separate obligations, see DAST vs Penetration Testing.

How is next-gen DAST different from legacy DAST?

Legacy DAST crawls and guesses, so it misses single-page apps, stalls on authentication and state, and can leave a significant share of active endpoints untested. Next-gen DAST inverts the order: it discovers the real API surface first, then tests it with session-aware, stateful crawling and LLM-assisted form handling. It verifies findings with request and response evidence instead of pattern-only alerts, ties API findings on source-discovered targets back to the exact source line (which we detail in Source-Linked DAST), tracks coverage across builds, and runs natively inside the pipeline with safe, rate-limit-aware defaults. That evidence requirement matters more as advisories themselves become cheap to generate: see SQLite Got a Critical CVE for a Vulnerability That Doesn't Exist for what happens when a finding arrives as a severity label with nothing behind it.

How does NightVision help with federal compliance such as FedRAMP, NIST, and EO 14028?

NightVision produces inputs that map to federal guidance rather than a compliance checkbox. Gray-box DAST operationalizes the "rigorous empirical testing" called for in OMB M-22-09 and CISA's Zero Trust Maturity Model, and its evidence-backed findings support FedRAMP control narratives across the AC, AU, CM, SC, and SI families. API discovery keeps endpoint inventories and OpenAPI specs current, which supports NIST SP 800-204 policy scoping and the accurate API inventories that EO 14028 and SBOM practices expect.

Do I still need SAST if I run DAST?

Yes, because neither approach sees everything. SAST reads code but cannot watch behavior, while DAST watches behavior but cannot read code, so each covers the other's blind spots. That is the whole premise of combining them. NightVision pairs discovery-driven DAST with auth-focused source-code analysis through API eNVy, but it is not a full SAST suite and does not sell IAST or SCA, so a mature program still complements it with broader static and dependency coverage.

Can my coding agent run security scans?

Yes, if the scanner exposes agent-ready interfaces. NightVision publishes an MCP server and agent skills, so any MCP-capable coding agent, including Claude Code, Cursor, GitHub Copilot, and Windsurf, can launch a scan, read each finding’s request and response evidence, draft a fix, and rescan to verify the finding is gone. The scan itself stays deterministic, and a human reviews and merges the change. See NightVision for coding agents.

Who security-tests apps built outside engineering?

The AppSec team does; the builders never need to touch a scanner. Finance dashboards, HR portals, low-code workflows, and AI-generated internal services are real applications with real APIs, and they rarely enter a security backlog on their own. Because a discovery-driven DAST platform like NightVision can test any reachable application black box from a URL, with authenticated coverage when credentials or a recorded login are provided, AppSec can onboard and test these apps without asking their builders to change how they work. See securing apps built outside engineering.