WordPress Dynamic Security Scan: Test the Live Application, API, and Commerce Attack Surface
Aegisify Dynamic Security Scan evaluates the behavior that a running WordPress site exposes over the web. Quick DAST provides focused public-facing validation, while Enterprise DAST: App & Commerce expands discovery and safe testing across application routes, REST APIs, GraphQL and OpenAPI signals, browser-facing assets, access-control boundaries, and Commerce workflows when those surfaces exist.
Aegisify uses profile-driven DAST to discover reachable surfaces, run safe validation, preserve evidence, prioritize findings, and support verification after remediation.
How Aegisify Turns a Live WordPress Site Into Dynamic Security Evidence
Open each stage for a high-level view. This public guide explains the assessment model without publishing internal scanner payloads, signatures, private routes, or exploitation logic.
Click a stage to expand
01Scopeexample.com
02DiscoverWeb + API surface
03EnrichAgent context when used
04Test SafelyDAST validation
05NormalizeFindings + evidence
06VerifyRescan + retest
DAST Examines the Running Application From the Outside In
Dynamic Application Security Testing evaluates how the deployed site responds to real web requests. That makes it complementary to vulnerability inventory and static code analysis rather than a replacement for either one.
A WordPress application can look healthy in a software inventory while still exposing weak headers, risky session behavior, unexpected API routes, unsafe input handling, browser-side leakage, access-control gaps, or business workflows that behave differently than intended. Dynamic testing helps answer whether those conditions are actually observable in the live application.
Aegisify separates this work into two public-facing profiles. Quick DAST is designed for fast recurring checks of the public surface. Enterprise DAST: App & Commerce is the broader default profile and adds deeper application discovery, API and browser coverage, access-control testing, route modeling, and Commerce-specific review when those components are present.
Choose Quick DAST for Speed or Enterprise DAST for Broader Application Truth
Both profiles use the same findings model, but the depth of discovery and validation is intentionally different.
Quick DAST
Quick DAST focuses on high-signal public exposure: web hardening, session and authentication posture, common input-handling weakness classes, REST visibility, sensitive artifacts, and baseline workflow protections. It is designed to be faster and does not require Agent scan stages.
Enterprise DAST: App & Commerce
Enterprise DAST includes the public baseline and expands into application routes, API security, access control, browser/client-side evidence, attack-surface graphing, safe workflow testing, and Commerce checkout, cart, payment, webhook, order, and compatibility posture when detected.
Baseline First, Depth When Needed
Use Quick DAST when you need a fast public check after routine changes. Use Enterprise DAST when the site behaves like an application, exposes APIs, uses Commerce, contains business workflows, or requires deeper evidence before release or remediation signoff.
The Dynamic Scan Reviews Nine Core Security Domains
Not every domain is active in every profile. Quick DAST intentionally uses a smaller subset; Enterprise DAST activates the broader model.
Headers, Caching, Cookies, and Sensitive Artifacts
Aegisify evaluates externally observable hardening controls, browser frame policy, content-security posture, session-cookie attributes, caching behavior, and sensitive installation or application artifacts that can reveal unnecessary information.
Input Handling and Unsafe Interpretation
DAST checks high-level classes such as reflected and stored client-side injection signals, database-oriented injection indicators, redirect handling, server-side request behavior, traversal-style input risk, and parameter interpretation weaknesses using safe validation logic.
Login Boundaries and Session Behavior
The scan reviews cookie security, session initialization, logout invalidation, timeout posture, authentication expectations, and related conditions that help determine whether a user session is isolated and handled consistently.
Object, Function, and Privilege Boundaries
Enterprise coverage looks for routes and APIs where authorization behavior may not match the intended role or object boundary, including object-level, function-level, and privilege-related candidates that deserve controlled validation.
REST, OpenAPI, GraphQL, and Inventory Truth
Aegisify inventories REST behavior and, where discovered, OpenAPI or GraphQL surfaces. Enterprise coverage reviews authentication expectations, exposed methods, data exposure, schema behavior, inventory quality, resource controls, and related API security posture.
DOM, Scripts, Source Maps, and Token Signals
Enterprise DAST examines fetched front-end assets for client-side risk signals, source-map exposure, script relationships, token or secret-like indicators, and browser-facing conditions that server-only testing can miss.
State, Nonces, and Sensitive Actions
Dynamic workflows are reviewed for request-state protections and safe replay behavior. In Commerce, this extends into cart, coupon, checkout, account, order, and payment-related workflow integrity without using destructive transaction logic.
File-Handling Attack Surface
Where file-upload workflows are discovered, Enterprise DAST identifies candidates that deserve review for file type, path, authorization, and processing posture. Public documentation intentionally omits the underlying test signatures.
Routes, Contracts, and Attack-Surface Relationships
Enterprise DAST builds normalized route and API inventory and can preserve an attack-surface relationship graph so teams can understand what was actually discovered and what downstream validation had meaningful scope.
Checkout, Payment, Webhook, Order, and Compatibility Context
When Commerce is detected, Aegisify adds dedicated coverage for Store API and REST exposure, checkout model, payment assets, webhook posture, cart and order workflows, HPOS, Action Scheduler, and template compatibility signals.
External DAST Leads the Assessment; the Agent Adds Internal Context Where the Profile Uses It
The two dynamic profiles have different Agent requirements, and that distinction matters when interpreting coverage.
Quick DAST Is Public-Facing by Design
Quick DAST has no Agent scan stages in its current profile. It discovers and validates the public surface directly. This makes it useful when the immediate question is, “What can an unauthenticated observer see and how does the live site respond?”
Enterprise DAST Adds Authorized WordPress Context
Enterprise DAST can request Agent-side hardening evidence, a local WordPress inventory, Commerce posture when WooCommerce is active, and local Aegisify-suite correlation. That internal evidence helps compare what the public scanner discovers with what WordPress itself knows about the environment.
SaaS Correlates Both Views
External discovery, active-safe DAST evidence, Agent results, discovered assets, API inventory, and route relationships are normalized into one run record. Aegisify also records coverage status so unavailable prerequisites are not silently presented as successful security validation.
Activity Sensors and Telemetry Are Supporting Controls, Not Hidden Requirements for Every DAST Run
The Agent separates local event collection, optional telemetry sharing, and profile-specific scan stages.
WordPress Activity Log sensors record supported WordPress events locally across users, settings, plugins, themes, core, files, content, taxonomy, comments, media, menus, options, and Aegisify Audit activity. Most sensors are enabled by default, while four noisy option-change sensors are disabled by default.
Telemetry Access Control is separate. Its master control and every telemetry category begin disabled. Administrators choose whether supported metadata such as software versions, integrity hashes, privileged-user inventory, cron/event inventory, recovery telemetry, snapshot differences, file drift, privileged configuration state, or optional log access may be made available.
For this Dynamic Security Scan family, sensors are not a direct execution prerequisite for Quick DAST, and the current Enterprise DAST profile does not fetch the WordPress Activity Log as a required scan stage. Enterprise Agent enrichment instead centers on local hardening, inventory, Commerce posture, and Aegisify product correlation. Approved telemetry can add context, but disabled telemetry does not turn public DAST discovery off.
What the Current Dynamic Scan Defaults Mean
Aegisify uses profile defaults so operators start from known coverage instead of assembling a scan from unrelated checks.
DAST Should Produce Evidence Without Becoming a Weaponized Exercise
Aegisify’s implemented rule catalog distinguishes passive observation, safe active validation, authentication prerequisites, and write-safe workflow requirements.
The public documentation intentionally describes vulnerability classes rather than the exact payloads, signatures, request mutations, retry thresholds, or internal scanner mechanics. That keeps the page useful to customers without making it useful as an evasion or attack guide.
Enterprise features also activate conditionally. OpenAPI review depends on discovering an in-scope definition or strong signal. GraphQL review depends on finding a GraphQL surface. Commerce checks run when Commerce is detected. Browser coverage in this build uses lightweight HTTP/DOM and asset discovery rather than claiming to be a full AJAX-rendered browser spider.
When an Agent connection is unavailable, Enterprise DAST can still perform its external stages, but the application records reduced Agent-backed coverage instead of silently implying that internal WordPress validation occurred.
The Output Is Designed for Triage and Verification, Not Just a Vulnerability Count
Aegisify normalizes discovery and test results so teams can move from “something looked suspicious” to an owned remediation workflow.
Dynamic findings can preserve the observed route or surface, request context, category, severity, confidence, evidence, false-positive guidance, remediation guidance, and standards mappings where the corresponding rule defines them. Rules can map to OWASP web/API categories, WSTG areas, and CWE identifiers; those mappings are technical references, not a certification claim.
After a fix, a new assessment can refresh the broader application view. The current DAST workflow also supports focused finding retests that create a new verification job tied to the original finding context. That helps teams validate remediation with fresh evidence rather than simply changing a status field.
Common Questions About Aegisify Dynamic Security Scanning
Is Dynamic Security Scan the same as a vulnerability inventory or SAST?
No. Dynamic Security Scan tests the deployed application and its reachable web/API behavior. Vulnerability inventory correlates software and dependency risk, while SAST inspects code and internal implementation patterns. The three methods answer different security questions.
Which profile is the current default?
Enterprise DAST: App & Commerce is the default Dynamic Security Scan profile. Quick DAST is available when a faster public-facing assessment is more appropriate.
Does Quick DAST require the Aegisify Audit Agent?
No. The current Quick DAST profile has no Agent scan stages. It is intentionally built around public exposure, normal crawling, REST discovery, and safe active validation.
What does the Agent add to Enterprise DAST?
The current Enterprise profile can add WordPress hardening evidence, metadata inventory, Commerce posture when WooCommerce is active, and local Aegisify-suite correlation. This gives SaaS an authorized inside-out context to compare against outside-in DAST observations.
Do sensors or telemetry have to be fully enabled?
No. Activity sensors and Telemetry Access Control are separate Agent features. Telemetry starts disabled and is customer-controlled. The base public DAST workflow does not depend on enabling every telemetry category, and Quick DAST does not use Agent scan stages at all.
Does Aegisify guarantee that a clean DAST result means the site is secure?
No. DAST validates the reachable behavior and coverage available to the selected profile at that point in time. Application changes, untested prerequisites, hidden workflows, third-party services, and new vulnerabilities can change risk. DAST should be combined with static, vulnerability, hardening, monitoring, and recovery controls.