API DAST: Discover the WordPress API Surface You Documented—and the Routes You Did Not
Aegisify API DAST is the advanced profile for runtime API attack-surface discovery and validation. It correlates WordPress REST evidence, browser- and JavaScript-exposed routes, API contract signals, OpenAPI and GraphQL evidence when present, front-end relationships, Agent inventory, and bounded active testing into a unified API security view.
DAST
What Is Aegisify API DAST?
API DAST evaluates the behavior and inventory of APIs exposed by the live verified WordPress application.
The profile is designed to discover more than the obvious WordPress REST routes. It can combine server-discovered endpoints, browser/client-side references, JavaScript-linked routes, documented API contracts, GraphQL/OpenAPI evidence when the application reveals those technologies, and Agent-side inventory context. Aegisify then normalizes those discoveries into route contracts and an API inventory before applying supported dynamic security tests.
The goal is not simply to produce a long endpoint list. It is to identify meaningful differences between what teams expect the API to expose and what the running application actually reveals, then evaluate authentication, authorization, object access, data exposure, input handling, resource-use posture, client-side relationships, and other API security conditions supported by the profile.
How API DAST Builds an Executable API Inventory
Open each stage to see the public workflow. Internal discovery guesses, endpoint dictionaries, payload values, and detector implementation are intentionally omitted.
Click a stage to expand
01Verify Scopeauthorized domain
02Discover SourcesREST + web + client
03Identify ContractsOpenAPI + GraphQL
04Normalize Inventoryroute state + relationships
05Validate BehaviorOWASP API-aligned
06Correlate Client RiskAPI + browser context
07Report & Retestinventory + findings
Where API DAST Looks for WordPress API Surface
Namespaces, Routes, and Methods
Maps reachable REST behavior and route characteristics exposed by WordPress core, plugins, themes, custom code, and application integrations within the authorized scope.
Routes Revealed by the Front End
Looks for API references surfaced by scripts and browser-visible application behavior, helping identify endpoints that may not appear in a conventional server-side crawl.
Documented Contract Evidence
When the application exposes relevant contract metadata, Aegisify can incorporate it into the route inventory and compare documented intent with observed runtime behavior.
Graph-Oriented API Surface
When GraphQL evidence exists in scope, the scanner can add that API style to the inventory and evaluate supported authentication, exposure, and resource-behavior signals.
Application-Driven API Discovery
Correlates web routes, forms, page states, and client behavior with API calls so the report can explain how an endpoint participates in the application rather than listing it in isolation.
Inside-the-Site Context
A connected compatible Agent can add WordPress-side inventory and correlation evidence that helps the SaaS reconcile externally discovered routes with the local application environment.
Documented Does Not Always Mean Complete
WordPress applications can accumulate API routes through plugin installation, custom code, commerce integrations, headless front ends, analytics, forms, membership systems, and JavaScript bundles. Some routes are intentional and documented. Others are legitimate but poorly inventoried. Others may be legacy, unnecessary, unexpectedly public, or visible only through client-side behavior.
Known Contract
Routes that align with available API documentation or expected application behavior provide the reference point for security review.
Runtime Reality
Routes observed through live discovery, scripts, browser behavior, WordPress APIs, or other in-scope evidence expand the operational inventory.
Needs Ownership Review
A route that is reachable but not represented in the expected inventory is not automatically a vulnerability. It is a governance and attack-surface signal that should be owned, justified, protected, or removed.
What API DAST Tests at a High Level
The current profile includes API, access-control, authentication/session, injection, browser/client, exposure, and inventory-oriented rule families.
BOLA / IDOR Candidates
Looks for evidence that object-oriented API operations may expose data or actions beyond the intended authorization boundary. Candidate conditions still require contextual review.
API Auth Expectations
Evaluates whether sensitive routes appear to require and enforce the expected authentication context and whether client-visible authentication artifacts introduce avoidable exposure.
Privilege-Oriented API Boundaries
Reviews route behavior for signals that a less privileged context may reach functionality intended for a more privileged application role.
Response Scope and Sensitive Fields
Looks for responses that appear broader than the intended client need, including potential excessive data exposure or unexpected information disclosure.
Contract and Parameter Handling
Reviews discrepancies between expected and observed input/response structure and looks for unsafe parameter-binding patterns that may deserve engineering review.
Rate and Pagination Posture
Assesses observable resource-control signals such as pagination and throttling behavior where they can be evaluated safely without stress testing the target.
Bounded Input Validation
Uses controlled, non-destructive validation to identify candidate API input-handling conditions without publishing the underlying probe strings or exploit logic.
Documented vs. Executable Behavior
Compares route and schema evidence to identify mismatches that can create blind spots for development, security testing, or API governance.
DOM, Scripts, Tokens, and Source Maps
Correlates client-side evidence with API routes to identify browser-observable risk signals that may increase the practical exposure of an endpoint.
OWASP API Top 10 2023OWASP Web mappingsOWASP WSTGCWE
How API DAST Combines External and Local Evidence
APIs Are Often Discovered Through the User Interface
Modern WordPress sites increasingly behave like applications. JavaScript can fetch data after page load, trigger background actions, reveal route templates, store client-side state, or connect to third-party services. API DAST therefore includes browser/client-oriented discovery in addition to traditional REST discovery.
Built-in analysis can inspect front-end route and script relationships. When the optional browser-assist service is configured for the verified domain, Aegisify can also ingest rendered route discovery, DOM coverage, click-path expansion, form inventory, and other post-render state to improve attack-surface mapping. The browser worker is treated as an inventory/validation component, not an exploit-delivery engine.
API Inventory Context Without Automatic Full Telemetry Sharing
The API DAST profile can request the Agent-side scan context it is authorized to use for inventory and correlation. Separately, the Agent provides customer-controlled telemetry categories that begin disabled. Those optional categories can include software versions, integrity hashes, administrative inventory, cron/event inventory, backup/restore telemetry, snapshot and file-drift history, privileged configuration states, and explicitly enabled log/activity access.
The Agent also maintains local WordPress activity sensors. These cover user, setting, plugin, theme, core, file, content, taxonomy, comment, media, menu, option, and Aegisify activity. Sensor collection and telemetry authorization remain different controls.
What API DAST Enables—and What Depends on Evidence
How API DAST Starts—and Where the Evidence Is Produced
Run Against a Verified Domain
An authenticated customer chooses API DAST in the advanced shortcode and launches it against an approved verified target. The profile records the API, browser/client, and Agent coverage selected for that job.
Recurring API Attack-Surface Review
API DAST can be scheduled on daily, weekly, or monthly cadences so changes introduced by WordPress, plugins, custom code, JavaScript, or integrations are reassessed over time.
SaaS + Site + Agent + Optional Browser
SaaS orchestrates external discovery and dynamic validation, the live verified site produces runtime behavior, the Agent contributes local inventory/correlation, and optional browser assistance expands rendered discovery.
Retest or Full Profile Rerun
Teams can use supported focused verification after a finding is fixed or rerun API DAST to rebuild the full API inventory and detect new, removed, or changed routes.
From Endpoint List to Security Decision
One Normalized Route View
Organizes discovered API routes and relevant state so teams can see what exists, how it was discovered, and where ownership or documentation may be incomplete.
Expected Characteristics
Records route behavior and contract evidence in a consistent model that supports authentication, method, schema, and response analysis.
Relationships Matter
Connects pages, scripts, APIs, authentication contexts, and other assets so security teams can see how a route becomes reachable within the application.
Prioritized API Risk
Groups findings into security families and normalized severity rather than forcing teams to interpret raw scanner events individually.
Know the Gaps
Shows where prerequisites or evidence prevented a test, helping reviewers distinguish lack of coverage from lack of findings.
Verify Change
Preserves normalized context for subsequent scans, latest-vs-previous comparison, and supported focused verification after a finding is remediated.
API DAST vs. Deep Auth vs. API DAST and Compliance
Authorization Is the Primary Question
Use Deep Auth DAST when you need post-login route discovery, multi-context visibility, session review, and deeper role/authorization comparison.
API Inventory and Runtime Behavior Are Primary
Use this profile when the main goal is to discover and validate REST, browser-exposed, documented, undocumented, OpenAPI, or GraphQL API surfaces and correlate them with client behavior.
You Also Need a Control Baseline
Use API DAST and Compliance when you want the API DAST workflow plus Agent-assisted application-security and database-posture controls mapped to supported DISA SRG/NIST references.
Common Questions
Does API DAST only scan the standard WordPress REST API?
No. The profile is designed to correlate REST behavior with client-side references, browser discovery, API contract evidence, and OpenAPI/GraphQL signals when those technologies are present in scope.
Does finding an undocumented route mean it is vulnerable?
No. An unexpected or shadow route is first an inventory and governance signal. Aegisify separately evaluates security-relevant behavior such as authentication, authorization, data exposure, or input handling before treating it as a vulnerability finding.
Will the scanner assume GraphQL exists?
No. GraphQL and OpenAPI coverage depend on in-scope evidence that the technology or contract is present. The profile is prerequisite-aware.
Is API DAST a load test?
No. The security workflow is designed around bounded validation. Resource-control posture may be observed, but the public product model is not a destructive stress-testing service.
Does API DAST replace SAST?
No. API DAST observes the running API and client surface. SAST Static Code Analysis reviews supported source patterns locally through the Agent. Use both when you need runtime and implementation-level assurance.